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ABSTRACT 


This  work  describes  the  logical  design  of  a  proposed  deci¬ 
sion  support  system  for  use  by  the  National  Communications 
System  in  forecasting  technology,  prices  and  costs.  It  is 
general  in  nature  and  only  includes  those  forecasting  models 
which  are  suitable  for  computer  implementation.  Because  it 
is  a  logical  design  it  can  be  coded  and  applied  in  many 
different  hardware  and/or  software  configurations. 
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I.  INTRODUCTION 


The  design  and  ccnstructicn  of  software  for  a  modern 
information  system  is  a  rigorous  process  which  can  be 
described  in  a  life  cycle  which  consists  of  the  following 
steps : 

1.  Feasibility  -  Defining  the  basic  approach  and  general 
scope  of  a  software  project,  with  particular  emphasis 
on  determining  the  practicality  of  such  a  project 
over  its  entire  life  span. 

2.  Requirements  -  Specifying  the  required  functions, 
interfaces  and  actual  performance  of  the  software 
system,  including  operational  constraints. 

3.  Design  -  Defining  data  flow,  algorithms,  data  repre¬ 
sentations  and  control  structures.  identifying  and 
specifying  modules.  Usually  entails  at  least  two 
iterations  of  refinement. 

4.  Coding  -  Translating  the  design  into  a  programming 
language.  Includes  testing  of  individual  components. 

5.  Integration  -  Individual  system  components  are  inte¬ 
grated  into  the  final  system  configuration. 

6.  I  irplementation  -  Installation  of  the  software  product 
with  the  host  hardware  system,  to  include  testing. 

7.  Maintenance  -  All  subsequent  alterations,  modifica¬ 
tions  and  improvements  made  to  the  complete  system. 

This  work  is  an  attempt  to  define  a  logical  software 
design,  based  on  general  system  requirements,  which  can  be 
"fine-tuned"  by  rigorous  specification  and  ultimately  used 
as  the  foundation  for  the  physical  implementation  of  a  deci¬ 
sion  support  system  (CSS) .  As  such,  it  does  not  strictly 
follow  the  prescribed  conventional  software  development 
process.  It  is,  rather,  a  hybrid  approach  at  addressing 
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several  cf  the  traditional  phases  of  the  life  cycle:  feasi¬ 
bility,  requirements  and  (logical)  design.  It  is  purposely 
of  such  a  general  nature  in  order  to  facilitate  specific 
system  requirements  and  ultimate  performance  of  the  entire 
software  development  life  cycle. 

One  of  the  underlying  design  principles  upon  which  this 
effort  is  based  is  that  of  software  generality.  An  auto¬ 
mated  system  to  forecast  telecommunications  technology, 
prices  and  costs  should  be  designed  in  such  a  manner  as  to 
allow  for  maximum  utility  within  the  proposed  scope  of 
application.  This  particular  DSS  logical  design  enables  the 
NCS  manager  to  model  a  wide  variety  of  technology,  price  and 
cost  situations  without  the  associated  overhead  imposed  by 
multiple  application-specific  systems. 

The  Manager  of  the  National  Communications  System  (NCS) 
has  been  tasked  by  the  National  Security  Telecommunications 
Policy  of  3  August  1983  with  implementing  this  policy  under 
the  direction  and  with  the  consultation  of  the  Policy 
Steering  Group.  As  part  of  this  task,  the  Manager  must: 

1.  Ensure  the  development,  in  conjunction  with  the  NCS 
operating  agencies,  of  plans  to  fulfill  the  princi¬ 
ples  and  objectives  stated  in  this  directive, 
including  an  overall  telecommunications  architecture 
and  timetable. 

2.  Develop,  for  review  by  the  Steering  Group,  overall 
budget  profiles  regarding  approved  initiatives  and 
related  activities. 

3.  Prepare  annually,  or  as  otherwise  directed,  a  written 
report  to  the  Steering  Group  on  the  progress  of 
approved  initiatives,  including  an  assessment  of  the 
resources  that  will  be  required  to  attain  the  objec¬ 
tives  of  this  directive  [Ref.  1]. 

For  a  manager  to  make  effective  decisions  and  to  prepare 
effective  and  timely  flans,  a  certain  amount  and  quality  or 


information  has  to  he  available.  Martino  [Ref.  2]  states, 
"One  of  the  best-kept  secrets  of  the  planning  profession  is 
that  planning  has  nothing  to  do  with  actions  to  be  taken  in 
the  future.  Instead,  planning  deals  with  actions  to  be 
taken  in  the  present." 

The  information  required  for  planning  into  the  future 
partly  consists  of  estimates  as  to  what  the  future  holds. 
The  NCS  must  have  estimates  of  what  technologies  will  be 
available  at  a  later  time  and  what  the  cost  and  price  of 
that  technology  will  be.  A  decision  support  system  system 
which  utilizes  forecasting  techniques  and  models  can  be  used 
to  derive  accurate  estimates  and  aid  NCS  managers  in  making 
decisions  based  upon  these  estimates.  Forecasts  of  tech¬ 
nology  are  useful  because  a  technological  change  can: 

1.  Frovide  new  methods  of  achieving  objectives. 

2.  Render  certain  means  of  achieving  objectives  obso¬ 
lete. 

3.  Render  certain  objectives  obsolete. 

The  necessity  to  track  technology  growth  is  particularly 
important  once  it  has  been  identified  as  a  reeded  tech¬ 
nology.  Isenson  [Bef.  3]  found  through  his  investigations  of 
Project  Hindsight  that  a  real  need  results  in  accelerated 
technological  growth.  The  greater  the  rate  of  the  growth  of 
a  technology,  the  more  it  can  influence  previously  made 
plans . 

This  paper  will  develop  a  decision  support  system  to 
forecast  technology,  prices,  and  costs  for  use  by  the 
National  Communications  System.  The  next  chapter  is  an 
overview  of  the  NCS.  Chapter  III  introduces  the  concept  of 
forecasting  and  forecasting  models,  with  a  discussion  on  how 
they  may  effectively  be  utilized  by  a  government  agency  such 
as  the  NCS.  The  actual  logical  design  for  the  decision 
support  system  will  then  be  developed  and  the  methods 
utilized  in  its  design  are  discussed.  The  conclusions  will 
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conventional  cost-estimating  daring  the  cost/benefit  anal¬ 
ysis  (concept  development  of  the  acquisition  cycle).  It  can 
te  used  to  evaluate  alternatives  during  strategic  planning. 
It  can  te  utilised  during  periodic  revisions  of  the 
Five-Year  Defense  Plan  (FYDP)  ,  or  similar  intermediate-term 
plan  for  GSA-procured  systems.  As  a  general  rule,  an  auto¬ 
mated  forecasting  system  would  be  ideal  for  use  whenever 
traditional  economic/technological  analysis  is  too  elabo¬ 
rate,  too  time-consuming  and/or  too  expensive  for  the  scope 
of  the  particular  problem  or  project  at  hand. 


D.  SOHHAEY 

Although  forecasting  models  are  well  suited  for  adapta¬ 
tion  to  automated  systems,  they  are  not  without  their  poten¬ 
tial  problems.  Depending  upon  the  real-world  project  and 
model  application,  forecasters  may  find  a  limited  number  of 
relevant  statistical  procedures  available.  Once 
constructed,  models  may  quickly  become  obsolete  by  the  rapid 
growth  of  tne  technology  being  forecast.  Hence,  effort  must 
be  directed  toward  a  method  for  adapting  the  model  for  tech¬ 
nological  advance  even  during  periods  of  rapid  growth.  The 
forecaster  may  be  confronted  with  the  mathematical  problem 
of  solving  k  equations  in  n  unknowns  (k  <  n) .  A  host  of 
problems  involving  accuracy  of  the  model  may  be  caused  by 
emission  of  a  relevant  exogenous  variable,  disregarding  a 
qualitative  change  in  one  of  the  variables,  inclusion  of  an 
irrelevant  variable,  incorrect  definition  of  a  variable,  and 
in  the  case  of  econometric  models,  incorrect  specification 
of  the  manner  in  which  the  stochastic  disturbance  term 
enters  the  equation. 

The  effects  of  divestiture  and  deregulation  of  the  tele¬ 
communications  industry  are  major  contributing  reasons  for 
the  National  Communications  System  to  consider  use  of  fore¬ 
casting  techniques.  As  the  NCS  continues  to  grow  in  size, 
scope  and  complexity  cf  participating  systems  (for  example, 
the  ccnversion  from  analog  to  digital  voice  circuits),  even 
more  powerful  tools  will  be  required  to  exert  effective 
managerial  control  over  further  development.  Accordingly, 
the  objective  of  forecasting  technology,  cost  and  price  is 
not  to  provide  a  managerial  decision,  but  to  derive  further 
inputs  to  the  managerial  decision-making  process.  Numerous 
potential  applications  exist  within  the  traditional 
Planning,  Programming  and  Budgeting  System  (PPBS)  and  acqui¬ 
sition  cycles.  For  example,  it  can  be  used  in  lieu  of 
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TABLE  2 

Major  Cost  Categories 


Research  and  Development  Costs 

All  costs  associated  with  the  research,  development, 
test  and  evaluation  of  the  eguipment/sy stem.  Normally 
these  costs  are  incurred  during  concept  initiation, 
validation  and  full  scale  development. 


Nonrecurring  Investment  Costs 

All  ccsts  incurred  one  time  beyond  the  program  devel¬ 
opment  phase  and  during  the  program  production  phase. 
These  costs  can  occur  if  there  is  a  change  in  design, 
contractor  or  manufacturing  process. 


Hec urr ing  Investment  Costs 

All  production  ccsts  that  recur  with  each  unit 
proc  uced . 


Operating  and  Maintenance  Costs 

All  ccsts  associated  with  personnel,  material,  facili¬ 
ties  and  other  costs  required  to  operate,  maintain  and 
support  an  equipment/system  during  its  useful  life¬ 
time. 


of  growth)  in  an  area,  it  can  be  estimated  that  the 
increased  ccmm un icat icns  among  researchers  will  result  in  an 
exponential  growth  cf  knowledge,  likely  to  result  in  a 
breakthrough  or  an  advancement  of  the  technology  tein j 
studied.  This  area  of  forecasting  can  be  directly  influ¬ 
enced  by  infusion  of  government  resources  into  research 
[Ref.  3].  If  a  certain  level  of  a  parameter  of  a  technology 
is  desired  by  a  certain  date,  the  amount  of  research  and 
development  necessary  now  can  be  estimated.  The  recent 
Presidential  initiative  regarding  the  so-called  "Star  Vlars" 
technology  is  an  example  of  this  technique. 
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TABLE  1 

Life  Cycle  Cost  Models 

Total  Life  Cycle  Cost  Model 

sociates  all  applicable  cost  elements  over  the  life- 
me  cf  a  system. 

Differential  Life  C^cle  Cost  Model 

Compares  differential  costs  between  two  similar  cost 
elements  of  two  different  systems. 

_ J 

as  model  parameters.  Table  2  is  an  explanation  of  the 
conventional  major  cost  categories. 

C.  TECHNOLOGY  POHEC  ASTING  MODELS 

Technology  forecasting  models  are  similar  to  price/cost 
models  in  that  the  primary  determinant  of  the  guality  cf  the 
forecast  is  in  the  variables  which  are  brought  into  the 
model  and  how  they  are  weighted  in  relation  to  one  another. 
Cnee  this  has  been  accomplished,  different  techniques  can  be 
utilized  to  fit  a  curve  to  the  historic  data  in  order  to 
project  the  value  of  the  technology  parameter  at  a  future 
time.  The  model  is  highly  dependent  upon  the  core  assump¬ 
tions  made  about  the  environment  which  is  being  forecast. 
In  particular  is  the  assumption  regarding  the  existence  of 
upper  limits  (or  lower  limits  in  the  case  of  time  reduc¬ 
tions)  on  the  capabilities  of  the  technology  being  modeled. 
An  example  of  an  upper  limit  assumption  would  be  the  speed 
cf  light  for  spacecraft  velocities.  Other  than  extrapo¬ 
lating  trends  into  the  future  by  curve  fitting,  technology 
forecasting  can  sample  the  amount  of  literature  circulating 
in  an  area  of  technology.  By  monitoring  the  growth  (or  lack 
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determines  values  of  certair  endogenous  variables,  the 
jointly  dependent  variables  which  are  simultaneously  solved 
by  the  relations  of  the  model.  Independent  exogenous  vari¬ 
ables  are  determined  outside  the  system  but  influence  it  by 
affecting  the  values  of  the  endogenous  variables.  They 
affect  the  system  but  are  not  in  turn  affected  by  it.  An 
econometric  model  is  an  algebraic  model  that  typically 
includes  one  or  more  random  variables  (disturbance  terms) 
and  represents  a  system  by  a  set  of  stochastic  relations 
among  the  variables  of  the  system.  Such  a  model  generally 
specifies  the  probability  distribution  of  each  endogenous 
variable,  given  the  values  taken  by  all  exogenous  variables 
and  given  the  values  of  all  parameters  of  the  model. 
[Ref.  9] 

A  cost  model  is  used  to  predict  the  anticipated  costs 
likely  to  be  incurred  in  a  project.  Like  other  models,  when 
a  cost  model  equation  or  system  of  equations  is  derived  from 
statistical  analysis  cf  a  sample  of  past  projects,  an  asso¬ 
ciated  factor  is  a  degree  of  imprecision  or  uncertainty. 
The  validity  of  the  model  is  a  function  of  how  widely  the 
data  are  scattered  around  the  prediction  line  or  curve. 
Cost  models  must  generally  be  individually  structured  to 
best  meet  the  purpose  for  which  they  are  intended  (Table  1)  . 
If  the  forecast  is  meant  to  aid  in  the  choice  between  alter¬ 
natives,  the  differential  life  cycle  cost  model  would  be 
used.  Such  a  model  would  compare  the  differential  costs 
associated  with  the  alternative  systems.  Detailed  compar¬ 
ison  between  the  alternatives  would  be  provided  by  summing 
the  differential  costs  identified  with  the  applicable  cost 
elements  chosen.  Conversely,  a  cost  model  based  upon  total 
life  cycle  cost  would  concentrate  on  applicable  cost 
elements  over  the  projected  life  expectancy  of  a  particular 
equipment  or  system.  The  model  builder  would  identify  the 
cost  categories  and  associated  cost  elements  to  be  utilized 


life  cycle.  The  forecaster  begins  the  process  by  identi¬ 
fying  facts  and  other  data  about  past  trends  and  previous 
forecasts  relating  to  the  problem  under  consideration. 
Particular  attention  is  given  to  determining  the  cause  of 
variances  between  previous  forecasts  and  actual  system 
behavior.  The  forecaster  must  next  determine  and  organize 
future  parameters  of  the  decision  problem.  A  suitable  model 
which  describes  the  problem  space  is  then  constructed,  along 
with  a  method  and  measure  of  accuracy  and  reliability. 
Luring  the  course  of  the  project,  periodic  samples  are  taken 
to  compare  the  forecast  with  actual  behavior,  documenting 
variances  as  they  occur.  Finally,  the  forecast  is  revised 
as  necessary.  [ Ref .  2] 

A  forecast  is  only  as  accurate  as  its  model,  and  a  model 
is  only  as  accurate  as  its  data  sources.  Moreover,  the 
model  used  represents  a  compromise  between  reality  and 
manageability.  It  must  identify  essential  factors  while 
disregarding  non-critical  ones.  A  good  model  specifies 
interrelationships  among  parts  of  the  system  such  that  it  is 
reasonably  detailed  and  explicit  to  ensure  the  model 
adequately  describes  the  real-world  system.  However,  it 
must  also  specify  them  in  such  a  way  that  it  is  understand¬ 
able  so  that  proper  analysis  and  conclusions  regarding  the 
real-world  system  can  be  made. 


B.  PBICE/COST  FOBECASTING  MODELS 


This  work  is  not  an  attempt  to  survey  the  entire  field 
of  available  forecasting  models.  The  focus  will  te  on  the 
most  common  type  of  parametric  model,  the  algebraic  model, 
which  is  particularly  well  suited  to  the  NCS  application 
because  of  the  ease  with  which  it  may  be  expanded  and  modi¬ 
fied.  The  algebraic  model  typically  consists  of  several 
equations,  each  with  a  separate  meaning  and  role.  The  model 


Historically,  federal  departments  and  agencies  have  utilized 
separate  estimation  and  analysis  units  within  each  stage  of 
the  acquisition  process.  In  addition,  each  unit  has  tended 
to  utilize  a  unique  costing  and  pricing  technique  for  each 
of  the  functional  specialties.  Furthermore,  as  each  esti¬ 
mate  and  analysis  is  forwarded  through  the  organizational 
hierarchy,  policy  reviews  and  revisions  take  place. 
Although  some  agencies  utilize  a  centralized  cost/price 
estimation  and  analysis  activity,  they  are  the  exception  to 
the  rule.  The  normal  process  entails  redundancy  of  effort 
and,  all  to  often,  results  in  poor  cost  and  price  informa¬ 
tion.  Certainly  it  is  given  that  the  adequacy  of  data  is  a 
major  factor  in  the  quality  of  cost  and  price  estimates  and 
analyses,  but  the  importance  of  the  overall  methodology 
utilized  must  not  be  discounted.  This  is  the  case  particu¬ 
larly  for  estimates  and  analyses  involving  new  technology 
and  major  systems. 

The  traditional  acquisition  costing/pricing  process  can 
be  significantly  enhanced  by  use  of  forecasting  techniques 
and  methods.  Forecasting  is  a  process  whose  objective  is  to 
predict  future  events  or  conditions  under  an  assumed  set  of 
circumstances.  The  most  common  applications  of  forecasting 
involve  the  use  of  estimating  models  to  predict  quantitative 
values  of  certain  variables  outside  the  sample  of  data  actu¬ 
ally  observed.  In  the  case  of  cost  and  price  forecasts, 
these  values  would  mcst  likely  assume  a  probability  d: stri- 
tuticn  rather  than  a  point  forecast.  Technology  forecasting 
looks  more  toward  the  time  period  by  which  certain  parame¬ 
ters  of  a  given  technology  will  be  achieved.  An  example  of 
this  would  be  to  forecast  the  year  in  which  90%  of  telecom¬ 
munications  common  carriers  will  be  using  digital  voice 
circuits  rather  than  analog  circuits. 

The  forecasting  process,  like  the  product  or  service  for 
which  the  forecast  is  made,  can  be  described  in  terms  of  a 


III.  USE  OF  FORECASTING  MODELS  IN  GOVERNMENT 


A.  CCSCEPTS 

The  general  concept  of  cost  and  price  projection  is  an 
integral  issue  associated  with  the  acquisition  of  major 
systems,  commercial  products  and  industrial  services  by 
agencies  of  the  federal  government.  This  concept  normally 
is  addressed  during  the  rigorous  process  known  as  economic 
analysis,  the  outcome  of  which  is  a  major  factor  either  in 
the  selection  of  a  choice  between  two  or  more  alternatives, 
or  in  assessing  the  economic  consequences  of  a  choice 
already  made  between  alternatives.  Unfortunately,  the 
literature  pertaining  to  economic  analysis  includes  rather 
generalized  and  imprecise  guidance  for  the  conduct  of  cost/ 
price  estimation,  key  elements  of  the  process.  In  practice, 
costing  and  pricing  within  the  federal  government  varies 
widely  from  agency  to  agency,  and  even  within  agencies  there 
may  be  variety,  dependent  upon  the  type  of  product  or 
service  being  acquired  [Ref.  8].  The  use  of  technology, 
price  and  cost  forecasting  models  is  one  method  available  to 
complement  and  enhance  an  agency's  established  employment  of 
economic  analysis  and  estimation  in  the  acquisition  life 
cycle . 

Regardless  of  the  scope  of  the  project  or  program 
involved,  the  acquisition  process  can  be  viewed  as  a  logical 
progression  of  iterative  reviews,  determinations  and  evalua¬ 
tions  to  reconcile  periodic  adjustments  to  program  objec¬ 
tives  and  requirements  or  resource  availability.  This 
process  overlaps  the  traditional  functions  of  planning, 
budgeting,  contracting  and  contract  administration,  each  of 
which  can  be  examined  as  an  area  of  specialization. 
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specialized  carriers  where  it  has  been  determined  to  be  mere 
convenient  for  the  government.  Such  exceptions  to  the  rule 
are  rare,  however,  primarily  due  to  the  paramount  necessity 
to  ensure  mutual  support  and  interoperability  among  the 
various  systems. 
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utilized  by  the  NCS  to  ensure  Federal  telecommunications 
systems,  derived  from  common  carrier  networks,  are  intercon¬ 
nected  and  capable  of  interoperation  to  the  maximum  extent 
possible . 

C.  PEOCUBEHEIT  OF  SEBVICES 

More  than  95%  of  the  communication  services  utilized  by 
the  Federal  government  and  its  agencies  within  the  conti¬ 
nental  United  States  are  provided  by  common  user  systems 
leased  from  and  operated  by  the  major  common  and  specialized 
commercial  carriers  (the  vast  majority  are  leased  from  AT&T 
Long  Lines  and  associated  Bell  operating  or  interconnect 
companies)  [Ref.  7].  "Common"  user  systems  means  that  the 
physical  facilities  from  which  the  government  services  are 
derived  are  usually  also  common  to  public  message  services 
with  provisions  made  to  segregate  the  two  services.  Close 
and  continual  coordination  between  the  NCS  and  the  private 
sector  telecommunications  industry  is  facilitated  by  the 
Federal  Communications  Commission  (FCC)  and  the  National 
Industry  Advisory  Committee  (NIAC) .  During  wartime  or  other 
national  emergency  the  authority  to  requisition  and  contract 
for  supplies  and  equipment,  and  to  restore,  expand,  repair 
and  construct  telecommunications  systems  is  delegated  to  the 
FCC.  However,  the  NCS  retains  overall  responsibility  for 
integrating  all  government  communications.  In  order  to 
perform  its  emergency  functions,  the  FCC  relies  heavily  upon 
the  NCS  Telecommunications  Emergency  Management  System 
(NTEMS)  . 

Peacetime  procurement  responsibility  is  centralized 
also,  but  divided  between  G3A  for  civil  agencies  and  the 
Defense  Communications  Agency  (DC  A)  for  DOD  systems. 
Certain  civil  agencies  and  components  have  been  authorized 
independent  authority  to  procure  directly  from  common  and 


2. 


Military  operational  communications  for  both  general 
and  nuclear  conflicts. 

3.  Communications  in  support  of  military  mobilization. 

4.  Communications  to  ensure  government  continuity  in  the 
event  of  nuclear  or  natural  disaster,  and  recovery 
from  the  same.  [Hef.  5] 

In  August  1983  the  national  telecommunications  policy 
was  further  defined.  The  new  policy  addresses  the  vulner¬ 
ability  of  existing  NCS  systems  to  nuclear  attack  and 
directs  enhancements  and  improvements  (i.e.,  switches  and 
control  centers)  be  physically  located  away  from  likely 
nuclear  target  areas  and,  whenever  feasible,  existing  system 
components  be  hardened.  [Hef.  1] 

Actual  policy  guidance  for  the  NCS  in  the  areas  of  tele¬ 
communications  planning  and  development  is  fragmented  and 
originates  from  multiple  sources  at  the  Executive  Office 
level.  For  example,  the  Office  of  Science  and  Technology 
Policy  (CSTP)  is  tasked  with  the  responsibility  for  the 
collection,  recording  and  evaluation  of  existing  telecommu¬ 
nications  facilities  and  the  development  of  profile  informa¬ 
tion  detailing  the  residual  capabilities  of  these  systems 
and  networks  under  various  extraordinary  conditions, 
including  nuclear  and  other  national  emergencies  [Ref.  6]. 
Such  information  is  used  by  the  NCS  in  the  conduct  of  resto¬ 
ration  and  allocation  activities,  resources  evaluation, 
damage  assessment,  requirements  evaluation,  and  priority 
determination.  The  OSTP  facilities  status  evaluation 
provides  the  NCS  raw  data  pertaining  to  system  gross  opera¬ 
tional  capabilities  in  terms  of  (1)  link/trunk  capability, 
(2)  call  demand/acceptance  capability  of  voice  switching 
systems,  (3)  message  processing  capability  of  record  traffic 
switching  systems,  (4)  user/subscriber  access  capability  of 
voice  and  record  switching  systems,  and  (5)  residual  major 
system  access  concentraters.  This  data  can  and  should  be 


4.  Fixed  route  government  owned  or  leased  transmission 
facilities  under  exclusive  control  of  a  government 
agency. 

5 .  -^Government  owned  or  leased  radio  systems^’ 

6.  Technical  control  facilities  which  are  under  exclu¬ 
sive  control  of  a  government  agency. 

7.  Other  services  provided  by  a  common  or  specialized 
carrier  on  a  continuing  basis,  via  commercial  facili¬ 
ties  not  designated  for  exclusive  government  use. 
These  services,  like  exclusive  use  services,  will 
still  be  assigned  an  appropriate  restoration  priority 
in  the  event  cf  national  emergency  or  other  disrup¬ 
tion  of  the  service.  [Ref.  4] 

Most  NCS  operating  component  systems  are  long-haul, 
trunk,  point-to-point  systems.  They  are  planned,  operated 
and  funded  by  their  sponsor  agencies  to  fulfill  a  specific 
peacetime  need.  The  current  NCS  management  doctrine  is  to 
provide  joint  central  planning,  standardization  and  program¬ 
ming.  The  long  range  goal  is  to  ensure  progressive,  system¬ 
atic  improvements  existing  systems  in  order  to  allow 
efficient  and  effective  transition  from  peacetime  to  emer¬ 
gency  conditions. 

B.  NCS  POLICY 

As  the  number  of  NCS  operating  components  has  grcwn  over 
the  years,  so  also  have  the  organizational  responsibilities 
and  system  complexities.  In  order  to  clarify  and  define  the 
NCS  goals  and  objectives,  the  National  Security  Council 
(NSC)  established  in  1979  the  National  Security 
Telecommunications  Policy.  This  policy  directed  the  NCS  to 
ensure  telecommunications  assets  provide  for: 

1.  Emergency  communications  between  the  National  Command 
Authority  and  appropriate  forces  to  support  retalia¬ 
tory  action  in  the  event  of  enemy  nuclear  attack. 


II.  THE  NATIONAL  CO  MMUNICATIONS  SYSTEM 


A.  OVERVIEW 


The  National  Communications  System  was  formed  cr.  21 
August  1963  as  a  result  of  a  recommendation  by  the  National 
Security  Council  that  the  Executive  Office  move  to  identify 
and  coordinate  the  communications  needs  of  the  Federal 
Government.  ->  Originally  envisioned  as  a  means  to  integrate 
the  many  systems  found  throughout  the  government,  the 
general  mission  of  the  NCS  continues  to  be  to  ensure  the 
survi veatility  of  communications  during  and  subsequent  to 
any  national  emergency.  In  order  to  accomplish  this  mission 


the  NCS  is^organized  not  as  a  homogenous,  separate  entity; 
rather,  it  is^an  arrangement  of  heterogeneous  telecommunica¬ 


tions  systems  which  are  provided  by  their  sponsor  Federal 
agencies.^  In  its  early  years  of  existence  the  NCS  was 
comprised  Mostly  of  General  Services  Administration  (GSA) 
and  Department  of  Defense  (DOD)  assets.  Today,  however, 
virtually  every  major  Federal  agency  is  a  participating 
member  of  the  NCS. 

The  physical  components  of  Federal  telecommunications 


systems  and  networks  included  under  the  NCS  may  he  described 
as  the  following:  . 
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Automatic  telephone  route  control  switching  facili¬ 
ties  and  associated  first  level  user  switching  facil¬ 
ities. 

Telephone  and  digital  data  switching  facilities  and 
primary  common  user  communications  centers. 

Special  purpose  local  delivery  message  switching  and 
exchange  facilities.* 


3. 


describe  why  the  particular  forecasting  models  implemented 
in  the  DSS  were  selected  and  also  discuss  possible  strat¬ 
egies  for  implementation  of  the  DSS. 
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IV.  PBELIMINABY  DATi  DICTIONARY  DESIGN 


In  ordei  to  develop  a  database  for  a  decision  support 
system  it  is  necessary  to  look  at  the  overall  requirements 
for  designing  such  a  system  with  special  emphasis  on  the 
data  which  will  be  utilized.  The  DSS  architecture  presented 
by  Dolk  [ Hef .  10]  consists  of  four  major  components:  (1) 
dialog,  (2)  model  base,  (3)  knowledge  base,  and  (4)  data¬ 
base.  The  dialog  is  the  primary  driver  of  the  system.  It 
is  the  interface  with  the  user;  therefore,  the  dialog  is 
dependent  upon  what  outputs  the  decision-maker  wants  from 
the  DSS  and  what  inputs  can  be  to  provided  to  get  that 
output.  The  model  base  will  provide  the  basic  algorithms  of 
the  system  models  as  well  as  the  value  abstractions  of  the 
coefficients  for  the  variables  to  be  utilized  by  the  model 
algorithms.  The  knowledge  base  contains  a  set  of  heuristics 
which  determine  what  type  model  or  combination  of  models 
will  be  processed  for  a  given  circumstance  provided  by  the 
user.  The  database  will  contain  the  structure  and  values  of 
all  data  in  the  DSS  which  is  subject  to  modification  and/or 
addition  by  the  user  without  modifying  the  program  itself. 
The  data  utilized  by  the  dialog,  model  base,  and  knowledge 
base  determine  what  will  be  in  the  database,  and  will  there¬ 
fore  be  examined  briefly  in  turn. 

A.  DIALCG 

The  "rule  of  thumb"  in  DSS  design  (or  in  any  systems 
analysis  for  that  matter)  is  to  first  determine  what  will  be 
the  outputs  and  inputs  to  the  system.  Because  all  interface 
with  the  user  is  through  the  dialog,  this  is  paramount  to 
determining  what  the  dialog  is  to  be.  The  prime  question  to 


be  asked  is,  "What  does  the  user  need  in  a  forecast  cf  tech¬ 
nology?"  The  answer  to  that  question  for  the  purposes  of 
this  DSS  is  that  the  decision-maker  wants  the  DSS  to  provide 
a  presentation  of  trends  for  a  given  parameter  in  an  area  of 
a  technology,  given  a  set  of  assumptions  and  optionally 
given  a  set  of  parameters  from  other  areas  which  may  impact 
upon  the  technology,  including  the  degree  to  which  they  do 
so. 

The  following  are  outputs  required  from  the  dialog: 

1.  A  list  of  the  assumptions  used  in  generating  the 

forecast . 

2.  The  type  of  model  (s)  being  utilized. 

3.  A  graphical  presentation  of  historical  data  versus 
time  extrapolated  by  one  of  the  models  to  get  an 
indication  of  a  trend,  whether  increasing,  decreasing 
or  steady  and  which  includes  the  scale  used,  whether 
linear  or  logarithmic. 

4.  The  source  of  the  data  on  the  graph  and  its  type, 
whether  subjective,  objective  or  estimate. 

5.  A  comparison  of  this  forecast  with  previous  fore- 

c  asts. 

6.  Which  parameters  of  the  model  are  exogenous  or 

endogenous  and  of  these,  which  can  be  influence!  by 
the  decision-maker. 

The  following  inputs  to  the  dialog  are  required: 

1 .  An  ability  to  create  data  with  these  characteristics: 
identifiers  for  name,  type  of  factor  it  is,  source  of 
the  data,  date  of  the  data  entry  and  date  of  the  data 
observation. 

2.  An  ability  to  alter  assumptions  and  parameters  in 

order  to  observe  any  changes  in  the  output.  This  can 
include  a  means  for  indicating  the  stochastic  nature 
cf  some  of  the  variables.  For  example,  in  a  price/ 
cost  model  the  expected  future  interest  rates  of 


treasury  bonds  may  be  estimated  as  a  triangular 
distribution  cf  the  interest  rate  around  a  most 
likely  value  for  the  interest  rate,  bounded  by  an 
estimated  high  value  and  low  value  which  can  then  be 
iterated  through  the  model  as  a  Monte  Carlo  simula¬ 
tion. 

3.  An  ability  to  create  different  model  equations  for 
input  into  the  model  algorithm. 

4.  An  ability  to  override  the  knowledge  base  and  select 
a  specific  model  to  run. 

E.  HCDEL  EASE 

This  DSS  utilizes  two  primary  models.  The  first  of  these 
is  a  curve  fitting  model  which  regresses  a  straight  lire  on 
the  plots  of  five  different  functions  of  the  factor  or 
aggregate  model  score  to  forecast.  These  functions  are  a 
Pearl  crcwth  function,  a  Gompertz  growth  function,  a  func¬ 
tion  in  which  the  natural  logarithm  of  the  dependent  vari¬ 
able  is  taken,  and  a  function  in  which  the  natural  logarithm 
of  the  dependent  variable  and  the  natural  logarithm  of  the 
independent  variable  are  calculated.  The  regression  which 
has  the  highest  correlation  factor  is  selected  for  use  in 
extrapolating  into  the  future.  This  method  of  forecasting 
has  been  selected  due  to  its  simplicity  and  intuitive  under¬ 
standing  of  the  process  by  a  manager.  The  second  model  in 
the  DSS  is  a  simple  cross  impact  analysis  model  developed  by 
Julius  Kane  [Hef.  2]. 

1 •  Scoring  Model 

A  scoring  model  will  take  different  factors  named  by 
the  decision-maker  and  combine  them  to  determine  an  aggre¬ 
gate  score  (hence  the  name  scoring  model) .  This  is  accom¬ 
plished  through  queries  directed  at  the  user  to  determine 


the  relationships  among  the  factors.  Any  factors  which  are 
essentially  the  same  are  eliminated  so  that  only  one  factor 
will  represent  that  area  in  the  model.  Next  the  factors  are 
grouped  to  determine  whether  they  are  additive  or  multipli¬ 
cative,  either  of  the  entire  model,  or  of  groups,  and  so  on. 
Care  must  he  taken  in  choice  of  multiplicative  factors,  for 
if  the  value  of  the  factor  is  zero,  then  all  of  the  factors 
which  it  multiplies  are  then  zero.  Weights  are  now  assigned 
by  the  user  to  the  different  groups  or  individual  factors. 
Desirable  and  undesirable  factors  and  groups  are  separated 
with  the  desired  factors  being  in  the  numerator  and  unfavo¬ 
rable  factors  being  placed  in  the  denominator.  This  is  the 
basic  model  equation  and  can  be  stored  as  such. 

The  user  must  identify  whether  the  data  is  subjec¬ 
tive  or  objective.  If  subjective,  the  user  will  utilize  a 
standard  scale  of  zero  to  nine  in  selecting  the  value  for 
the  factor,  while  objective  data  will  be  examined  and  the 
mean  and  standard  deviation  for  each  factor's  data  being 
calculated.  The  mean  of  the  data  can  then  be  assigned  a 
value  of  the  user's  choice,  and  the  other  values  determined 
as  fractions  of  the  standard  deviation  to  range  from  a  low 
to  a  high  value  also  of  the  decision-maker's  choice. 

This  type  of  model  is  useful  in  comparing  different 
technologies  which  perform  similar  missions.  An  example 
drawn  from  telecommunications  technology  is  a  comparison  of 
satellite  communications  versus  landlines  versus  microwave 
links.  For  determining  the  relative  vulnerability  of  each 
to  disaster  or  nuclear  attack,  a  subjective  factor  can  be 
utilized,  while  cost  of  maintenance  or  installation  will  be 
an  objective  factor. 

2 •  fearl  and  Gompert z  C ur ves 

These  two  curves  are  discussed  jointly  because  they 
are  essentially  the  same  functions,  differing  mainly  in  the 


underlying  assumptions.  Both  curves  are  "S"  shaped  and  are 
extrapolated  by  first  straightening  out  the  curve  as  plotted 
by  the  factor  data.  This  is  accomplished  by  taking  the 
logarithm  of  the  curve,  once  for  the  Pearl  curve,  twice  for 
the  Gompertz  curve.  The  data  thus  transformed  has  a 
straight  line  regressed  on  it  to  obtain  the  values  for  the 
curve  functions.  The  equation1  for  the  Pearl  curve 
(Equation  4.1)  and  its  algebraic  transformation  (Equation 
4.2)  utilize  In  a  as  the  constant  and  b  as  the  slope,  b 
taken  to  be  positive.  L  is  the  assumed  limitation  of  the 
technology  and  t  is  time  while  y  is  the  value  of  the  factor 


y  =  L/  (1  +  a  *  (e  **  (-b  *  t) ) ) 


(4.1) 


Y  =  (L  -  y) /y  =  In  a  -  b  *  t 


(4.2) 


under  consideration.  The  Gompertz  curve  equation  (Equation 
4.3)  and  its  algebraic  transformation  (Equation  4.4)  utilize 
In  b  as  the  constant  and  k  as  the  slope.  The  other  two 


y  =  L  *  (e  **  (-b  *  (e  **  (-k  *  t)  ) ) ) 


(4.3) 


Y  =  In  (In  (L/y) )  =  In  b  -  (k  *  t) 


(4.4) 


variables  are  the  sane  as  before. 

The  different  assumptions  underlying  the  choice  of 
these  twc  curves  is  in  the  dynamics  of  the  technology  being 
forecast.  If  the  previous  progress  in  implementation  or 
development  of  a  technology  will  influence  the  rate  of  the 
progress  of  the  technology,  then  a  Pearl  curve  should  be 


1The  following  translations  describe  notations  which  may 
be  unfamiliar  to  the  reader: 

***  =  multiplication  operator 

****  =  exponentiation  operator 
'In*  =  natural  logarithm  function 


used.  However  if  the  determining  factor  is  how  much  remains 
to  be  accomplished  before  the  assumed  limit  to  growth  of  the 
technology  is  reached,  then  the  Gompertz  curve  should  be 
utilize  d. 

An  example  of  the  use  of  the  Pearl  curve  is  a  fore¬ 
cast  of  the  number  cf  households  which  have  access  to  a 
broadband  commun ica ticns  media.  The  factor  in  this  instance 
is  the  number  of  homes  with  cable  television  installed.  The 
maximum  limit  {’I’)  is  that  100%  of  households  which  have 
televisions  have  cable  installations.  A  Pearl  curve  is 
appropriate  because  the  technology  is  driven  by  the  degree 
of  acceptance  with  which  it  is  received  by  the  public. 

A  forecast  of  the  percentage  of  common  carrier  local 
distribution  systems  which  will  have  optical  fiber  as  the 
transmission  media  can  be  modeled  by  a  Gompertz  curve.  The 
limit  in  this  example  is  for  100%  of  existing  local  distri¬ 
bution  systems  to  have  been  replaced  by  optical  fiber 
systems.  Since  this  substitution  is  influenced  more  by  the 
number  of  systems  remaining  to  be  upgraded  rather  than  by 
the  number  of  systems  which  have  already  been  implemented,  a 
Gompertz  curve  is  the  correct  growth  curve  for  the  forecast. 

3  •  Cross  Impact  Analysis 

This  is  a  simple  model  which  takes  a  factor  in  an 
area  cf  a  technology  and  determines  the  next  value  it  will 
have  as  a  result  of  the  impact  of  other  factors,  both  exoge¬ 
nous  and  endogenous.  The  model  is  simple  in  that  only  the 
impact  of  a  single  variable  upon  another  variable  is  deter¬ 
mined  at  a  time,  not  all  variables  at  once.  The  inputs  by 
the  decision-maker  are  purely  subjective  evaluations  of  what 
the  impacts  of  certain  chosen  variables  are  upon  the  factor 
being  evaluated,  plus  the  original  value  of  this  factor 
(subjectively  scaled  from  zero  to  one  in  increments  of 
0.001).  The  use  of  such  a  model  is  for  a  decision-maker  to 


get  an  idea  of  the  results  of  varying  the  impacts  of  other 
factors  upon  a  factor.  Therefore,  it  is  necessary  for  the 
impacting  factors  to  be  defined  as  either  endogenous  or 
exogenous  variables  so  that  the  decision-maker  will  know 
which  variables  are  able  to  be  influenced.  An  example  of  an 
application  of  this  model  is  found  in  Chapter  VI. 

C.  KH0W1EDGE  BASE 

The  knowledge  base  of  this  particular  DSS  does  not  have 
anything  stored  in  the  database.  The  rules  for  determining 
which  models  to  run  are  within  the  algorithms  of  the  program 
itself.  The  only  impact  upon  the  data  dictionary  is  in  the 
identification  of  objects  passed  by  the  dialog  to  the  knowl¬ 
edge  base.  This  would  consist  of  determining  whether  a 
request  for  a  model  run  is  for  more  than  one  specific  area 
of  a  technology,  which  would  activate  a  scoring  model  to 
arrive  at  a  conglomerate  representation  of  the  overall  tech¬ 
nology,  or  in  determining  whether  a  Pearl  or  Gompertz  curve 
is  to  be  utilized  in  extrapolation  of  the  data.  The  cross 
impact  model  will  be  invoked  when  the  user  specifically 
directs  that  it  be  run. 

E.  DEVELOPMENT  OF  THE  DATA  DICTIONARY 

The  technique  to  be  utilized  in  the  development  of  this 
ESS  is  drawn  from  the  works  of  Yourdon  [Ref.  11]  and  DeMarco 
[Ref.  12].  Their  methods  of  structured  analysis  and  design 
result  in  a  logical  flow  toward  a  complete  software  design 
without  the  large  amounts  of  paper  normally  associated  with 
a  software  design  project.  The  less  documentation  which  has 
to  be  changed  in  later  design  revisions  of  the  DSS,  the 
greater  the  possibilit  '  that  the  documentation  will  be 
updated  to  reflect  chang  made  to  the  actual  software.  The 
essential  elements  of  t.  DeMarco  and  Yourdon  methods  are 
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the  development  of  a  data  flow,  a  data  dictionary,  and  the 
process  descriptions.  In  order  to  develop  the  data  flow, 
the  composition  of  the  data  inputs  and  outputs  to  the  system 
have  to  le  described  in  the  data  dictionary.  The  data  flow 
will  only  show  the  flow  of  the  data  objects  through  the 
system,  while  the  process  descriptions  provide  information 
about  the  content  and  processing  of  the  data. 

The  data  objects  are  described  in  the  data  dictionary 
primarily  through  the  use  of  the  three  types  of  relations 
presented  by  3ohm  and  Jacopini  [Ref.  13],  These  are 
sequence,  selection  and  iteration.  Sequence  is  a  concatena¬ 
tion  of  two  or  more  data  objects  and/or  data  elements 
together.  Selection  is  a  choice  between  two  or  more  data 
items.  Iteration  is  the  repetition  of  a  data  object,  or 
group  of  data  objects,  zero  or  more  times.  In  addition  to 
these  relations,  an  optional  relation  is  added  so  that  it  is 
possible  to  indicate  if  a  data  object  may  or  may  not  be  part 
cf  a  larger  data  object.  For  this  data  dictionary  a  data 
element  is  considered  to  be  data  which  is  not  further  broken 
down  into  other  data  elements.  The  level  to  which  a  data 
element  is  broken  down  is  left  to  the  user  and  the  data 
dictionary  designer.  A  data  object  may  be  oroken  down  into 
component  data  objects  and/or  data  elements.  Table  3 
explains  the  notation  utilized  in  this  data  dictionary. 

The  data  dictionary  for  the  DSS  is  developed  by 
analyzing  the  descriptions  of  the  dialog,  model  base  and 
knowledge  base  in  the  previous  sections.  This  will  result 
in  an  initial  look  at  how  data  objects  may  flow  through  the 
system.  Because  this  is  the  initial  version  of  the  data 
dictionary  it  is  inevitable  that  the  data  objects  will 
change,  be  added,  or  be  dropped  if  it  appears  during  further 
design  of  the  system  that  they  will  not  be  utilized  by  the 
system.  Usually  a  data  flow  technique  is  utilized  in 
analyzing  an  existing  system  in  order  to  automate  it.  This 
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TABLE  3 

Data  Dictionary  Notation 


Notation 

X  Consists  Of 

X 

= 

a  ♦  b 

data  objects  a  and  b 

X 

= 

I  a  1  fc  ] 

either  a  or  b 

X 

= 

fa} 

zero  or  more  occurances  of 

X 

= 

(a) 

optional  data  element  a 

X 

= 

y  fa} 

y  or  more  occurances  of  a 

X 

= 

fa}  z 

z  or  fewer  occurances  of  a 

X 

= 

y  fa} z 

between  y  and  z  occurances 

design  is  different  in  that  an  attempt  is  being  made  to 
design  a  system  which  does  not  yet  exist.  Therefore  the 
data  dictionary  depicted  in  Table  4  is  admittedly  of  a 
preliminary  nature. 

with  the  use  of  this  data  dictionary  an  initial  data 
flow  can  be  constructed.  The  data  flow  will  be  expanded  to 
different  levels  until  the  transformation  of  the  input  data 
to  the  output  data  is  fully  described.  Upon  the  completion 
of  the  expansion  of  the  data  flow  the  process  descriptions 
will  be  written.  These  descriptions  will  be  compared  with 
the  data  dictionary  in  order  to  determine  if  any  of  the  data 
is  not  utilized  or  if  there  is  data  which  must  be  added  to 

lata  dictionary.  The  data  is  then  normalized  and  a  data 
str  JctuL  i  i.ijiam  is  constructed.  With  the  addition  of  the 
format  ir,  which  the  data  will  actually  be  stored,  the  data 
dictionary  will  be  complete  and  serve  as  a  reference  docu¬ 
ment  during  the  detailed  design  of  the  decision  support 
syst  em. 
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TABLE  4 

Preliminary  Data  Dictionary 


ALGORITHM_NAME 

CHARACTERISTIC 

CATE 

DATE_CF_ENTRY 
DAT E_ OBSERVATION 

DISTRIBUTION 

ELEMENT 

ELEME  NT_ANALYSIS 
ELEMENT_ENTRY 

ELEMENT_SOURCE 
ELE  ME  NT_V  ALUE 

FACTOR 


♦Name  of  a  modeling  algorithm 
used  as  part  of  key  to 
identify  a  data  object  which 
contains  the  data  which  will 
be  used  by  a  model* 

[ "Exogenous" | "Endogenous"  ] 
♦Identifies  whether  data  is 
controllable* 

"MM/CD/YY" 

DATE 

♦Date  data  entered  into 
database* 

DATE 

♦Date  data  for  ELBMENT_ENTR Y 
observed  or  estimated* 

[ "Norm"| "Uni"! "Tri"  ] 

♦  How  stochastic  variable 
is  distributed* 

♦Sub-area  within  a 
technology* 

[  "Historical" | " Estimate"  ] 

DATE  OF  OBSERVATION 
ELE  M'S  NT~  SOURCE 
DATE  OF- ENTR Y 
ELEMT!NT-V  ALUE 
ELE  MENTHA NALY SI S 

♦Source  of  data  for 
ELEM  ENT_ENTR Y* 

MOST  LIKELY  VALUE 
(HIGH  VALUE- 
LOW  VILUE 
DISTRIBUTION) 

FACTOR  IDENTIFIER 

FACTOR~TYPE 

(UNITSf 

CHARACTERISTIC 
(ELEMENT  ENTRY} 


Table  4 

Preliminary  Data  Dictionary  (cont*d) 


FACTOE_IDENTIFIER 

FACTOR_OPERATOR 
FACTOR_TYPE 
F  ACTOR_W EIGHT 

GECUP_IDENTIFIER 

GRCUP_IEVEL 

3  ECU  P_0 PER ATOP 
GRCOP_WEIGHT 

GROUPS 

H IGH_ VALUE 

I M  ?  ACT_  FACTOR 

IMPACTIN  G_F  A  C  TO  R 
LIMITING  FACTOR 


=  TECHNOLOGY 
ELEMENT 

=  GROOP_OPERATOR 

=  [ "Subj"|  "Obj"  ] 

=  *Any  positive  integer  -  a 
subjective  evaluation  of 
the  factor  in  the  sub¬ 
group* 

=  *  A  unique  name  within  the 

data  object  to  identify 
a  grouping* 

=  *An  integer  greater  than  0 
used  to  indicate  which  other 

?  roups  this  group  acts  on 
he  lower  number  groups  act 
on  all  groups  of  higher 
number* 

=  [ ''Mult")  "Add"  ] 

=  *Any  real  number  -  a 

subjective  valuation  of  the 
group  in  the  model* 

=  GROUP  IDENTIFIER 
GROUP-OPERATOR 
GROUP- WEIGHT 
GROUP-LEVEL 
{SUB  GROUP 
SUB  GROUP  WEIGHT 
S  UB^GROU  P~ OPERATOR} 

=  *Any  real  number  greater 
than  or  equal  to  the 
ELEMENT  VALUE'S 
M0ST_LIKELY_ VALUE* 

=  *  A  subjective  value  -  a 

single  digit  0-9* 

=  FACTOR_IDENTIFI ER 

=  FACTOR  IDENTIFIER 
FACTORTYPE 
(UNITST 

CHARACTERISTIC 
1  {ELEMENT  ENTRY}  1 
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Table  4 

Preliminary  Data  Dictionary  (cont'd) 


LC V<  VALUE  =  *Any  real  number  less  than  or 

equal  to  the  ELEMENT  VALUE'S 
MOST_LIK  ELY_V  AL  U  E*  " 

MCDEL  =  ALGCRITHM  NAME 

MODEL  IDENTIFIER 
{GROUPS} 

(LIMITING  FACTOR} 

{IMPACTING  FACTOR 
IMPACT_FACTOR} 

MODEL  IDENTIFIER  =  *Name  given  by  user  used 

along  with  ALGORITHM_NAME 
to  identify  the  data  object 
containing  the  data  to 
be  modeled* 

MCST_II KELY_V ALU E  =  *Any  real  number* 

SC  ALE_FOR_DATA  =  [ "Linear " | "Log”  ] 

SUB  GROUP  =  SUB  GROUP  IDENTIFIER 

fSUl  GROUP 

SUB  GROUP  HEIGHT 

SUB- GROUP- OPERATOR} 

(FACTOR  “ 

FACTOR  OPERATOR 
FACTOR- WEIGHT} 

*  A  recursive  definition 
Sub-groups  may  contain 
other  subgroups* 

SUB  GROUP  IDENTIFIER  =  *A  unique  name  ftr  a  sub¬ 
group  within  the  group* 

5  U  E_  G  E  C  U  P_0  p  E  E  AT  0  R  =  GF.CUP_OPEE ATOR 

SUE_GROU?_WEIGHT  =  *Any  positive  integer  -  a 

subjective  evaluation  of  the 
SUB  GROUP  in  the  GROUP  or 
S  UB— GROUP* 

TECHNOLOGY  =  *Name  of  a  technological  area 

at  user's  discretion* 


UNITS 


♦Units  of  measure  for 
ELEM ENT_ENTR Y ' s* 


7.  PROCESS  SPECIFICATIONS 


The  process  specifications  are  descriptions  of  each  of 
the  nodes  in  the  system  where  data  flows  are  transformed 
from  one  form  of  composition  into  another  composition.  A 
characteristic  of  these  specifications  is  that  each  should 
descrile  an  underlying  policy  of  the  system,  specifying  what 
is  to  be  accomplished  rather  than  how  to  accomplish  it.  To 
do  this  they  are  writ-  ?n  in  a  form  known  as  Structured 
English.  Structured  English  is  a  form  of  English  in  which 
the  majority  of  nouns  used  will  come  from  the  data 
dictionary.  A  reserved  list  of  words  is  utilized  to  denote 
the  actions  within  the  process.  Examples  of  words  from  this 
list  are  those  words  which  use  the  three  techniques  of 
program  construction.  For  sequence  structures  statements 
within  a  program  should  follow  one  another.  Ic  show  decision 
the  usual  constructs  are  *  If ...  then  ...  else  ’ ,  'If. ..then',  or 
’ If . . .t hen. . . ot herwise For  multiple  decisions  some  varia¬ 
tion  of  a  'Case'  structure  is  employed  (i.e..  Case  of  This, 
Do  This,  Do  That,  Do  The  ether  Thing).  Iterations  are 
expressed  as  ' Fepeat ...  Until  some  condition  is  met', 'While  a 
condition  is  present  do...',  or  'For  a  certain  number  of 
times  do...'.  A  thorough  treatment  of  the  topic  is  provided 
in  [ Ref.  12  ]. 

The  process  specifications  written  here  are  referred  to 
as  process  mini-specifications  or  'mini-specs',  due  to  the 
fact  that  each  specification  is  unique  to  itself  and 
describes  a  smaller  system  contained  within  the  whole- 
system,  each  having  its  specified  inputs  and  outputs.  To  the 
remainder  of  the  system  the  process  will  appear  to  be  a 
'black  box'  with  in  puts  going  in  and  outputs  coming  out, 
somehow  transformed  ty  the  process.  In  this  chapter  the 


inputs  and  outputs  for  each  process  are  listed.  The  under¬ 
lying  policy  of  each  process  is  provided  to  indicate  what 
the  process  is  to  do.  Due  to  the  length  of  the  mini-specs, 
they  have  been  placed  in  a  separate  appendix.  Prior  to  each 
mini-specif ication  the  inputs  and  outputs  along  with  their 
respective  sources  and  destinations  are  provided.  Following 
the  mini-specifications  are  the  McCabe  complexity  numbers  of 
the  processes,  and  a  description  of  the  basis  paths  of  the 
processes. 

A.  THE  MCCABE  COMPLEXITY  METBIC  IN  SOFTWARE  DESIGN 

The  McCabe  Cyclcmatic  Complexity  Measure  was  first 
developed  for  testing  of  already  coded  modules.  McCabe’s 
paper  [Ref.  14]  presents  the  idea  of  applying  a  complexity 
measure  in  the  design  phase  of  software  design.  Previously 
this  metric  had  only  been  applied  to  completed  code.  The 
reasoning  behind  application  of  this  metric  in  the  design 
phase  is  that  many  more  errors  occur  in  the  design  phase 
than  in  the  coding  phase.  This  fact  is  demonstrated  by  the 


TABLE  5 

Relative  Frequency  of  Design  and  Coding  Errors 


Source  Statements 

Design  Errors  Coding  Errors 

Modif ication 

(No.) 

{%) 

<*) 

A 

1253 

73.6 

26.4 

E 

9880 

73.  7 

26.3 

C 

779 

35.6 

64.4 

E 

5  63  1 

51.6 

48.  4 

E 

4575 

58.8 

4  1.2 

data  in  Table 

5  which  is  from  a 

sof  tware 

reliability  study 

conducted  at 

TRW  of  the  percent 

of  errors 

introduced  in  a 

series  of  modif ica tic rs  to  a  large  software  project  (100,000 
lines  of  code)  [Ref.  15].  The  extension  of  the  McCabe 
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DO. 


og  Curve  Forecast 


Generate  estimates  of  data  over  the  period  in 
which  data  was  observed  using  a  Logarithmic  curve  formula, 
then  calculate  the  estimated  value  for  the  data  with  an 
upper  and  lower  limit  for  a  50%  confidence  interval.  This 
information  is  provided  for  each  interval  from  the  end  of 
observed  data  to  the  Fnd-Period  of  the  user  request. 


Inputs;  VARIATE 

IDENTIFIER 
RSGRESS_AN ALYSIS 
FACTOR_VIEW 
MODEL  VIEW 


Source:  Process  4.3.1 
Process  4.3.1 
Process  4.3.1 
Process  4.3.1 
Process  4.3.1 


Outputs:  EX? ANDE D_MCDEL_V ISW  Destination:  Manager 

EXPANDED_FACTOR_VIEW  Manager 

EXPANDED  FACTOR  VIEW  Process  4.3.1 


n.  Double-Log  Curve  Forecast 


Generate  estimates  of  data  over  the  period  in 
which  data  was  observed  using  a  Double-Logarithmic  curve 
formula,  then  calculate  the  estimated  value  for  the  data 
with  an  upper  and  lower  limit  for  a  50%  confidence  interval. 
This  information  is  provided  for  each  interval  from  the  end 
of  observed  data  to  the  End-Period  of  the  user  request. 

Inputs:  VARIATE  Source:  Process  4.3.1 

IDENTIFIER  Process  4.3.1 

REGRESS_ANAIYSIS  Process  4.3.1 

FACTOR_VIEW  Process  4.3.1 

MODEL  VIEW  Process  4.3.1 


Outputs:  EXP  ANDE D_MCDEL_ VIEW 
EXP  ANDE D_  FACTO R_V IEW 
EXPANDED  FACTOR  VIEW 


Destination:  Manager 
Manager 
Process  4.3.1 
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EXPANDED  FACTOR  VIEW 


k.  Gompertz  Curve  Forecast 


Process  ..3.1 


Generate  estimates  of  data  over  the  period  in 
which  data  was  observed  using  a  Gompertz  curve  formula,  then 
calculate  the  estimated  value  for  the  data  with  an  upper  and 
lower  limit  for  a  50/t  confidence  interval.  This  information 
is  provided  for  each  interval  from  the  end  of  observed  data 
to  the  End-Period  of  the  user  request. 


Inputs:  VARIATE 

IDENTIFIER 


REGRESS_ANAIYSIS 
FACTOR_VIEW 
MCDEL  VIEW 


Source:  Process  4.3.1 
Process  4.3.1 
Process  4.3.1 
Process  4.3.1 
Process  4.3.1 


Outputs:  EXP  ANDED_KCDEL_VIEW  Destination:  Manager 


EXP  ANDED_  FACTOR_V IEW 
EXPANDED  FACTOR  VIEW 


Manager 
Process  4.3.1 


1.  Linear  Curve  Forecast 

Generate  estimates  of  data  over  the  period  in 
which  data  was  observed  using  a  Linear  curve  formula,  then 
calculate  the  estimated  value  for  the  data  with  an  upper  and 
lower  limit  for  a  50U  confidence  interval.  This  information 
is  provided  for  each  interval  from  the  end  of  observed  data 
to  the  End-Period  of  the  user  request. 


Inputs:  VAF.IATE 

IDENTIFIER 


REGRSSS_ANAIYSIS 
FACTOR_V IEW 
MODEL  VIEW 


Source:  Process  4.3.1 
P  rocess  4.3.1 
Process  4.3.1 
Process  4.3.1 
P rocess  4.3.1 


Outputs:  EXPANSE D_ MCDEL_V IEW  Destination:  Manager 


EXPANDED_FACTOR_VIEW 
EXPANDED  FACTOR  VIEW 


Manager 
Process  4.3.1 
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Outputs:  DEPENDENT 
INDEPENDENT 

i.  Calculate  Regression 


Destination:  Process  4.3.  1.3 
Process  4. 3.1.3 


Calculate  A,  B,  the  correlation  coefficient,  and 
the  standard  error  cf  3  through  simple  regression.  The 
dependent  variable  (an  adjusted  or  unadjusted  Element- Value) 
is  regressed  on  the  independent  variable  (an  adjusted  or 
unadjusted  Observation-Date). 


Inputs:  DEPENDENT 

DATA_POINTS 

INDEPENDENT 


Source:  Process  4. 3. 1.1 
Process  4. 3 . 1 .  1 
Process  4. 3.  1 .  1 


LAST  OBSERVED  INTERVAL 


Process  4. 3.  1 . 1 


Outputs:  REGR£SS_ ANALYSIS 
REGR  ESS_A  NAL YS IS 
REGRESS_ANALYSIS 
REGR  ESS_ANALYSIS 
REGRESS  ANALYSIS 


Destination:  Process  4.3.2 
Process  4.3.3 
Process  4.3.4 
Process  4.3.5 
Process  4.3.6 


Pearl  Curve  Forecast 


Generate  estimates  of  data  over  the  period  in 
which  data  was  observed  using  a  Pearl  curve  formula,  then 
calculate  the  estimated  value  for  the  data  with  an  upper  and 
lower  limit  for  a  50/?  confidence  interval.  This  information 
is  provided  for  each  interval  from  the  end  of  observed  data 
to  the  End-Period  of  the  user  reguest. 


Inputs:  VARIATE 

IDENTIFIER 

F,  EGR  ESS_AN  AIYSIS 

FACTOE_VIEW 

MODEL_VIES 

Outputs:  EX?  A  NDED_  FCDEL_V I EW 
EXPANDED  FACTOR  VIES 


Source:  Process  4.3.1 
P rocess  4.3.1 
Process  4.3.1 
Process  4.3.1 
Process  4.3.1 

Destination:  Manager 
Ma  nager 
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Overriding  Groups  multiply  the  e:.  ire  model. This  product  is 
the  Mcdel-Score. 

Inputs:  MODE L_ STRUCTURE  Source:  Process  4.1.4. 1 

AVG_VALUE  Process  4.  1.4.1 

Outputs:  HOD EL_SCO RE  Destination:  Process  4. 1.4.1 

g.  Initialize  Functions 

Determine  the  set  cf  formulas  which  will  be  used 
to  convert  observed  data  into  a  linear  form.  The  possible 
five  curves  are  the  Pearl  curve,  Gompertz  curve,  linear  (no 
change) ,  a  logarithmic  curve  using  the  natural  logarithm  cf 
the  dependent  variable  (the  element-value),  and  a  double- 
iogar ithiric  curve  using  the  natural  logarithm  of  both  the 
dependent  (element-  value)  and  independent  variable 
(observation-date).  If  there  are  no  Factor  or  Model  Limits 
then  the  Pearl  and  Gcmpertz  curves  can  not  be  utilized. 

Inputs:  MODEL_VIEW  Source:  Process  4.1 

FACTOR_VIEfl  Process  4.  1 


Outputs:  DATA_P0IN1S 
A VG_V  ALUE 
END_I NTER  VAL 
CURVE 
LIMIT 


Destination:  Process  4. 3. 1.3 
Process  4. 3. 1.2 
Process  4. 3.1.2 
Process  4.  3 . 1 .2 
Process  4 .  3.1.2 


h.  Calculate  Curve  Functions 


Adjust  the  Avg-Values  and  Observation-Dates  into 
a  form  which  may  be  linear  using  the  Gompertz,  Pearl, 
Logarithmic,  or  Double-Logarithmic  equations. 

Inputs:  LIMIT  Source:  Process  4.3.  1.1 

A  VG_VALU  E  Process  4.3.  1.1 

END_TNTER V AI  Process  4.3.  1.1 

CURVE  Process  4. 3.  1.1 
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d.  Screen  Factor  Values 


interval . 
number  cf 
which  has 

Inputs:  BARS_FACTOE_VIEW 
ELEMENT_ VALUE 

Outputs:  FACTO  R_VI EW 
FACTOR_VI EW 

e.  Scoring  Model 


historical  data  within  an 
the  values  and  note  the 
and  the  last  interval 

Source:  Process  4.1.1 
FACTOR  File 

Destination:  Process  4.1.4 
Process  4.3 


Screen  Factor  File  for 
Calculate  the  average  of 
values  in  each  interval 
any  historical  data  in  it. 


Ensure  an  interval  has  at  least  one  data  point 
in  it  prior  to  calculating  the  Model-Score.  If  there  are  no 
data  points,  go  to  the  next  interval. 


Inputs:  MODEL_LIMIT 

MODEL_STRUCTURE 
FACTOR_VIEW 
MCDE  L_SCOR  E 

Outputs:  MODEL_STR UCTURE 
AVG_V  ALUE 
MODEL  VIEW 


Source:  Process  4.1.2 
Process  4.1.1 
Process  4.1.3 
Process  4 .  1.4.2 

Destination:  Process  4.  1.4.2 
Process  4.  1.4.2 
Process  4.3 


f.  Calculate  Model-Sccre 


Calculate  score  of  a  single  interval  cf  a  model 
using  the  Model- Structu~e  and  the  Avg-Values  passed  to  it. 
The  Factors  which  make  up  each  Sub-Group  are  multiplied  by 
their  Factor-We ights  and  then  summed  together.  All 
Sub-Groups  are  multiplied  by  their  Sub-Group  Weights.  The 
Sub-Groups  which  are  the  components  of  each  Group  are  multi¬ 
plied  together  and  then  multiplied  by  the  Group-Weights. 
Desirable  Groups  are  divided  by  undesirable  Groups. 
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substituting  the  estimated  values  for  each  factor  in  the 
model.  When  observed  data  is  not  available  then  this  is 
carried  out  through  a  Monte  Carlo  simulation  using  a  random 
distribution  between  the  upper  and  lower  confidence  limits 
ox  the  estimate. 

a.  Limit  Choices 


Determine  the  beginning  and  ending  time  of  each 
interval  of  the  user's  request. 


Inputs:  FIRM_S ELECT 

MCDSL_ STRUCTURE 
FACTOR_LIM IT 

Outputs:  BAR  E_ FACT CE_ VIEW 
EAR  E_FACTCR_VIEW 
MODEL_S  TRDCTURE 
MODEL_STRUCTURE 

b.  Check  For  Model 


Source:  Process  2 

MOD EL_STR UCTUR E  File 
FACTOR  File 

Destination:  Process  4.1.3 
Process  4.1.2 
Process  4.1.2 
Process  4.1.4 

imit 


Check  to  see  if  Model-Limit  can  be  calculated 
from  data  available.  If  all  Factors  in  a  model  have  a 
Factor-Limit  then  a  Model-Limit  can  be  calculated. 


Inputs:  MODEL_STRUCTURE  Source:  Process  4.1.1 

FACTOR_LIM IT  Process  4.1.1 

Outputs:  MODEL_LIMIT  Destination:  Process  4.1.4 

c.  Calculate  the  Model-Limit 


Calculate  the  Model-Limit  usin^  the 

Factor-Limits  for  each  Factor  in  the  model  and  using  the 
Model-Structure  of  the  designated  Model-Id. 

Inputs:  MO DEL_STR UCTUR E  Source:  Process  4.  1.2.1 

FACTOR_LIM IT  Process  4.  1.2.1 

Outputs:  MODEL_LIMIT  Destination:  Process  4.1.4 
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Operator 
Calendar 
FACTOR  File 


ELEMENT_VAIUE 
DATE_OF_ENTBY 
UNITS 

Outputs:  ELEMENT_E  NTRY  Destination:  FACTOR  File 
ENTR Y_SCR  EEN  Operator 

4 .  Forecast 

This  group  of  processes  execute  the  forecast  of  the 
model  or  factor  selected  by  the  user.  The  forecast  is  made 
by  fitting  five  types  of  curves  to  the  observed  data.  The 
curve  with  the  highest  correlation  coefficient  is  utilized 
for  the  forecast.  A  default  confidence  interval  of  50%  is 
applied  for  the  forecast.  The  results  of  the  forecast  are 
provided  to  the  manager  in  a  tabular  format.  If  individual 
factors  are  forecast  then  the  results  are  placed  in  the 
Factor  file,  with  an  ELEMENT_ANALYSI S  of  "Estimate”, 
ELE ME  NT_ SOURCE  is  the  CURVE  used  for  the  forecast,  and 
EATE_CF_ENTR Y  and  D ATE_0F_0BSE RV AT ION  are  the  date  and  time 
the  forecast  was  completed. 

In  the  case  of  forecasting  models  three  possible 
combinations  are  available.  If  all  of  the  factors  which  make 
up  the  model  have  a  factor  limit  then  a  model  limit  can  then 
be  calculated  by  utilizing  the  factor  limit  in  place  of  the 
factor  values  in  the  scoring  model  and  executing  the  model. 
This  would  enable  Pearl  and  Gompertz  curves  to  be  calcu¬ 
lated,  because  these  curves  require  an  upper  limit  to 
growth.  The  model  can  then  be  executed  as  normal  with  the 
model  limit  used  in  these  two  equations  in  place  of  the 
factor  limit.  If  some  factors  in  a  model  have  no  factor 
limit  then  only  the  linear,  logarithmic,  and  double  loga¬ 
rithmic  curves  are  available  for  fitting. 

There  is  also  the  option  of  forecasting  each  indi¬ 
vidual  factor  along  the  curve  with  the  best  fit  and  then 


4  7 


t.  Set  Default  Values 


Provide  default  values  for  any  parameters  not 
specified  by  the  manager.  These  default  values  are  a  period 
of  the  forecast  using  data  from  15  years  prior  to  the 
present  date  to  15  years  beyond  the  present  date  into  the 
future.  The  default  interval  is  one  year.  For  the  Monte 
Carlo  selections  the  default  number  of  iterations  is  100. 


Inputs:  USER_SELECT 
TODA  YS_D AT  E 
MODEL  STRUCTURE 


Source:  Process  2. 1 

Calendar 

MODEL  STRUCTURE  File 


Outputs:  FIR  M_SELECT 


Destination:  Process  2.1 


c.  Ensure  Sufficient  Data  Available 


Check  the  Factor  File  to  ensure  that  there  are 
at  least  3  data  points  within  the  user  specified  time  period 
for  each  Factor  necessary  to  the  forecast.  If  the  selection 
is  for  a  cross-impact-analysis  then  this  process  is  not 


necessary. 

Inputs:  FIRM_SELEC1 
FACTOR 
F  ACTOR_ID 

Outputs:  VALIDATION 
3  .  Element  Entr  y 


Source:  Process  2.  1 
FACTOR  File 
Process  2 . 1 

Destination:  Process  2.1 


This  process  allows  operators  to  add  values  tc  the 
factors  in  the  Factor  file.  It  is  a  screen  formatted  entry 
and  allows  little  leeway  for  the  operator.  Errors  are 
possible  if  the  operator  enters  the  wrong  units  for  the 
ZLE 'IE  NT_  VALUE  in  spite  of  the  prompting  by  the  process. 


Inputs:  F ACTOR_ID 

D ATE_0  F_OB  SER  VATIO  N 
EIEMENT  SOURCE 


Source:  Operator 
Ope  rator 
Operator 
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c.  Addition  to  Factor  File 


If  a  Factor  is  a  new  Factor  then  get  all  infor¬ 
mation  necessary  for  use  in  later  analyzing  or  forecasting 
it . 


Inputs:  FACTOR_ID 
FACTOR 


Source:  Process  1.2 
Manager 


Outputs:  FACTOR 


Destination:  FACTOR  File 


2 •  Model  Management 


The  purpose  cf  this  process  is  to  interpret  the  user 
command  and  forward  the  selection  of  the  user  for  either 
analyzing  or  forecasting  of  the  factor  or  model  selected. 
Check  to  see  if  the  selected  factor  or  model  is  in  the  data¬ 
base.  Any  default  values  of  the  selection  are  set  and  the 
overall  validity  of  the  user’s  selection  is  verified.  If  it 
is  not  valid  the  user  is  notified  of  that  fact  and  allowed 
to  reenter  a  selection  command. 

a.  Model  Validation 


Ensure  that  the  user 
options  in  his  selection  command 

Inputs:  USER_SELECT 

US3R_SSLEC1 
MODEL_STRUCTURE 
FIR  M_SELECT 
VALIDATION 

Outputs:  FIR  M_SELECT 
FIR  M_SEL  ECT 
F  ACTO  R_I D 
FIRM  SELECT 


made  a  valid  selection  of 

Source:  Manager 

Process  6 
Process  2.2 
Process  2.3 
Process  2.2 

Destination:  Process  4 
Process  6 
Process  5 
Process  2.2 
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a. 


Scoring  Model  Construction 


Get  the  Factors  (or  Factor)  which  the  manager 
wishes  to  be  part  of  a  model  or  which  will  be  forecast  or 
analyzed  at  a  later  time. 


Inputs:  MODEL_ID 

GROUP 
FACTOR_ID 
SU3_G  ROUP 

Outputs:  MOD EL__S TR  UCTUR E 

FACTOR  ID 


Source:  Manager 

Manager 
Ma  nager 
Process  1.2 

Destination:  MODEL_STRUCTURE 

File 

Process  1.2 


b.  Sub-Group  Organization 


Arrange  Factors  in  Sub-Groups.  Assign  each 
Factor  a  weighting  value  and  each  Sub-Group  a  weighting 
value.  Criteria  for  placing  factors  together  in  a  Sub-Group 
are  whether  they  are  both  either  "desirable"  or  "undesi¬ 
rable"  and  that  they  can  be  traded  off  against  one  another. 
Otherwise  they  are  in  separate  Sub-Groups.  There  is  no  limit 
to  the  number  of  Sub-Groups  or  Factors  in  a  Sub-Group. 
However,  single  Factors  do  have  to  be  assigned  to  a 
Sub-Group. 


Inputs:  FACTOR_ID 

SUB_GROUP_IC 
SU3_GR00 P_W  EIGHT 
FACTOR_W EIGHT 

Outputs:  SUB_GBOUP 
FACTOR  ID 


Source:  Process  1.1 
Manager 
Manager 
Manager 

Destination:  Process  1.1 
Process  1.3 


determined  by  data  conditions  at  the  decision  points.  Two 
examples  of  sets  of  basis  paths  for  figure  5.1  are  shown  in 
table  6. 


TABLE  6 

Two  sets  of  Basis  Paths 


Set  #  1 


Set  #  2 


hi:  abcegheikl 
b2:  abdfikl 
b3:  abceikl 
b4:  abceghl 
1 5:  abdfgkl 


abdf jkl 
abceikl 
abdfikl 
abc  (egh)  3eikl 
abc  (egh)  *  1 


The  notation  (egh)  3  means  to 
iterate  the  loop  (egh)  3  times 


E.  PROCESS  DESCRIPTIONS 
1 •  flodel  Building 

The  purpose  of  these  processes  is  to  construct  a 
format  for  new  factors  or  groupings  of  factors.  If  it  is  a 
grouping  of  factors  being  constructed  then  identify  the 
groups,  the  sub-groups,  the  group,  sub-group,  and  factor 
coefficients  (weights),  each  groups  level  within  the  model, 
and  the  sub-groups  and  factors  of  which  they  are  composed. 
If  there  are  new  factors  being  formatted  then  obtain  their 
factor  identifiers,  factor  types,  characteristics,  and  the 
subjective  impact  of  the  world  and  the  factor  itself  upon 
the  factor.  If  there  are  any  factors  which  impact  upon  the 
factor  being  formatted  then  obtain  their  factor  identifiers 
and  their  subjective  impact  upon  the  factor  being  formatted. 


Figure  5. 1  Graph  G. 

five  independent  paths  from  node  ’a*  to  node  '1'.  There  is 
no  one  correct  set  cf  independent  paths,  but  there  is  a 
basis  of  five  paths.  For  example,  there  couLd  be  iterations 
of  a  loop  within  the  module.  The  identification  of  the 
number  of  paths  in  the  basis  set  does  not  tell  how  many 
iterations  as  the  loop  should  be  processed;  that  is 


validated  by  a  software  reliability  study  [Ref.  16]  which 
demonstrated  that  procedures  of  already  coded  software  with 
10  or  more  basis  paths  accounted  for  a  much  greater  share  of 
the  errors.  When  processes  are  coded  and  compiled,  their 
complexity  will  increase  by  2  or  3;  therefore,  in  the  soft¬ 
ware  design  the  complexity  should  be  seven  basis  paths. 

The  theory  behind  the  complexity  metric  is  based  on  a 
definition  and  theorem  from  graph  theory. 

Definition  1.  The  cyciomatic  number  v(G)  of  a  graph  G 
with  n  vertices,  e  edges,  and  1  connected  component 
results  in  the  equation: 

v  (G)  =  e  -  n  ♦  1  (5.1) 


Vertices  are  also  kncwn  as  nodes  and  an  edge  can  be  consid¬ 
ered  a  path  from  one  node  to  another. 

Theorem  1.  In  a  strongly  connected  graph,  the  cycio¬ 
matic  number  is  equal  to  the  maximum  number  of  linearly 
independent  paths. 

A  strongly  connected  graph  is  one  in  which  there  is  a 
single  entry  point  and  a  single  exit  point.  All  paths  go 
from  the  entry  point  to  the  exit  point.  Furthermore  there  is 
a  path  from  the  exit  point  to  the  entry  point.  A  module  can 
be  considered  to  be  represented  by  a  strongly  connected 
graph  because  there  is  a  single  entry  point  from  the  calling 
module  and  the  module  returns  control  to  that  entry  point 
when  it  is  through  processing. 

'When  a  control  graph  is  drawn  to  represent  the  flew  of 
control  through  a  module,  there  is  usually  no  indication  of 
the  path  from  the  ending  point  to  the  entry  point.  McCabe 
remarks  that  this  edge  does  not  have  to  be  drawn  in,  but 


complexity  metric  to  the  design  testing  of  processes  will 
help  to  identify  logic  path  errors  and  will  provide  the 
number  of  basis  paths  through  a  process.  A  basis  path  is 
one  of  the  set  of  possible  independent  paths  from  the  entry 
point  of  the  process  to  the  exit  point  from  the  process. 
The  set  does  not  include  variations  from  the  independent 
paths  due  to  iterations  of  statements  along  the  path. 
Knowledge  of  these  paths  helps  to  determine  the  makeup  of 
the  test  data  to  be  utilized  later  in  testing  the  coded 
designs. 

The  primary  purpose  of  the  McCabe  Cyclomatic  Complexity 
measure  (henceforth  referred  to  as  "the  complexity  measure") 
is  to  limit  the  number  of  independent  paths  in  a  process. 
Yourdcn  and  Constantine  [Ref.  11]  present  the  idea  that  an 
acceptable  guideline  for  the  length  of  a  process  is  that  the 
Structured  English  syntax  or  decision  table  be  no  more  than 
one  page  in  length.  They  acknowledge  that  this  is  a  very 
general  guideline  but  that  it  should  be  utilized  in  addition 
to  ensuring  that  a  process  be  strongly  cohesive.  However,  as 
pointed  cut  by  McCabe,  a  50  line  process  with  25  selection 
statements  will  result  in  33.5  million  control  paths. 

In  order  to  determine  what  the  complexity  of  a  process 
should  be,  it  must  first  be  established  how  complex  a 
process  may  be  before  a  programmer  can  no  longer  effectively 
and  rapidly  understand  it.  Throughout  managerial,  psycholog¬ 
ical,  and  software  engineering  literature  this  complexity 
limit  is  known  as  the  Hrair  limit.  As  applied  to  software 
design,  it  has  been  determined  to  be  seven  logical  events, 
plus  or  minus  two  logical  events  [Ref.  14].  The  application 
of  this  limit  to  processes  is  that  the  number  of  basis  paths 
through  a  process  should  be  limited  to  seven.  Such  a  limit 
will  aid  in  testing  and  maintenance  due  to  the  ability  of 
the  maintenance  personnel  to  review  the  design  and  guicklv 
grasp  the  purpose  of  a  process.  This  application  has  been 


c. 


Monte  Carlo 


< 


b 


LI 


[* 


Provide  the  actual  Model-Score  and  the  estreated 
Model-Sccre  over  the  intervals  with  observed  data.  The  esti¬ 
mate  is  arrived  at  through  use  of  the  estimated  factor 
values  for  each  Factor  in  the  model  substituted  in  a  scoring 
model.  For  the  intervals  with  no  observed  data  a  503  confi¬ 
dence  interval  is  established  using  the  upper  and  lower 
estimates  for  each  Factor  of  the  model  and  substituting  them 
into  a  scoring  model.  Then,  for  number  of  times  specified  by 
the  user,  a  random  value  between  the  upper  and  lower  esti¬ 
mates  for  each  Factor  is  used  for  calculating  the 
Model-Sccre. 


Inputs:  FIEM_S ELECT  Source: 

EXPAN DED_FACTOR_VIEW 
MODEL_VIEW 
MODE L_ STRUCTURE 
MODEL  SCORE 


Process  4.1 
Process  4.3 
Process  4.1 
Process  4 . 1 
Process  4.4.2 


Outputs:  MONTEC ARLC_FOREC AST  Destination:  Manager 

MODEL_STR  UCTURE  Process  4.4.2 

AVG  VALUE  Process  4.4.2 


p.  Calculate  Model  Score 


Calculate  score  of  a  single  interval  of  a  model 
using  the  Model-Structure  and  the  Avg-Values  passed  to  it. 
The  Factors  which  make  up  each  Sub-Group  are  multiplied  by 
their  Factor-Weights  and  then  summed  together.  All 
Sub-Groups  are  multiplied  by  their  Sub-Group  Weights.  The 
Sub-Groups  which  are  the  components  of  each  Group  are  multi¬ 
plied  together  and  then  multiplied  by  the  Group-Weights. 
Eesiratle  Groups  are  divided  by  undesirable  Groups. 
Overriding  Groups  multiply  the  entire  model. This  product  is 
the  Model-Score. 


Inputs:  MODEL  STRUCTURE 


Source:  Process  4.4.1 


AVG  VALUE 


Outputs:  MODEL_SCORE 


Process  4.4.1 


Destination:  Process  4.4.1 


5  •  Cross  Impact  Analysis 

This  process  utilizes  the  simple  cross  impact  anal¬ 
ysis  model  devised  ty  Kane  as  discussed  in  [Bef.  2].  It 
searches  the  database  for  the  values  it  requires  and  does 
not  require  any  interaction  by  the  user.  Any  changes  tc  the 
model  will  be  made  in  the  Model  Management  process. 

a.  Cross  Impact 

Construct  a  Cross- Impact-Matrix  of  Factors  which 
impact  on  a  single  object  Factor.  This  matrix  also  includes 
the  impacts  of  the  other  Factors  upon  each  other.  The  impact 
of  the  outside  world  only  impacts  upon  the  Factors;  the 
Factors  do  not  impact  upon  the  outside  world. 


Inputs:  FACTOR_ID 

IMPACT_FACTCRS 
FACTOR  IMPACTS 


Source:  Process  2.0 
FACTOR  File 
FACTOR  File 


Outputs:  CROSS_I MPACT_MATRIX  Destination:  Manager 


CROSS  IMPACT  MATRIX 


t.  Calculate  Impact 


Process  5.2 


Over  a  relative  period  of  time  calculate  the 
cumulative  effects  of  the  values  of  the  Cross-Impact-Matrix 
upon  a  set  of  subjective  Initial-Values  provide  by  the 
manager  for  each  Factcr. 

Inputs:  CROSS_IMPACT_ MATRIX  Source:  Process  5.1 
INITI AL_V  AIUE  Manager 


Outputs:  PELATIVE_TIME 
VALUE 


Destination:  Manager 
Manager 
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Model  Change 

The  user  may  change  selected  variables  withir.  the 


model  which  has  most  recently  been  executed  and  then  execute 
it  again.  For  a  model  forecast  the  Group-Weight, 
Sub-Group-Weight,  and  Factor-Weights  may  be  changed.  If 
desired,  the  modified  model  may  be  given  a  new  name  and 
placed  in  the  Model-Structure  file.  The  Factor-Limit  of  a 
Factor  or  of  Factors  in  a  model  may  be  changed  and  the  model 
run  again.  The  selection  parameters  may  be  altered  to  change 
the  time  period  looked  at,  the  interval  within  the  time 
period  or,  if  the  selection  was  for  a  model,  a  Monte  Carlo 
forecast  rather  than  a  regular  forecast  {and  vice  versa)  may 
be  chosen. 


INITI AL_VAIUE 

Source:  Process  5 

FACTOR_VIEW 

Process  4 

MGDEL_ STRUCTURE 

Process  4 

CFOS  S_IMPACT_M ATR I X 

Process  5 

FIRM_S  ELECT 

Process  2 

GR0UP_V7  EIGHT 

Manager 

SUB_GROUP_W EIGHT 

Manager 

FACTOR _W E IGHT 

Manager 

F  ACTOR__LI  M  IT 

Manager 

MODEL_ID 

Manager 

MODEL_STRUCTURE 

Destination:  Process  4 

MODEL_STRUCTURE 

MODE  L__STRUC  TURF 

File 

FACTO  R_VI EK 

Process  4 

CROSS_IMPACT_MATRIX 

Process  5 

INITIAL  VALUE 

Process  5 

VI.  APPLICATIONS  OP  THE  DSS 


The  ISDN  concept  is  the  integration  of  digital  voice, 
circuit-switched  data,  and  packet-switched  data  networks 
into  a  single  network.  The  user  of  an  ISDN  would  not  be 
aware  of  which  of  these  types  of  networks  would  be  utilized 
to  complete  a  connection  to  a  destination.  The  network  would 
select  the  required  type  of  network,  the  choice  of  which 
would  be  transparent  to  the  user,  but  is  accessed  at  a 
single  pcint.  An  ISDN  architecture  for  the  national  backbone 
and  distribution  telecommunications  systems  could  be  desir¬ 
able  by  the  NCS  as  it  would  simplify  the  problem  of  inte¬ 
grating  the  present  mix  of  communications  networks  in  a 
national  emergency. 

The  rate  at  which  an  ISDN  architecture  will  evolve  in 
the  United  States  can  not  easily  be  mandated  by  regulation 
due  to  the  increasing  number  of  private  companies  and 
government  agencies  involved  in  construction  and  maintenance 
of  telecommunications  systems.  As  pointed  out  in  Chapter  1, 
the  impetus  for  growth  of  a  technology  comes  from  a  need  for 
that  technology.  In  the  United  States,  it  is  estimated  that 
private  users  provide  85%  of  the  needs  driving  the  evolution 
of  the  common  carrier  network.  Only  20%  of  the  private  users 
provide  80%  of  the  use  of  the  common  carrier  networks 
[Ref.  17].  Therefore,  to  forecast  the  growth  of  ISDN  tech¬ 
nology,  it  is  necessary  for  the  manager  to  forecast  the  need 
for  an  ISDN  by  private  users. 

The  forecast  DSS  described  in  this  paper  can  be  utilized 
to  forecast  that  user  need  for  an  ISDN.  The  method  for  doing 
this  is  for  the  NCS  to  collect  data  on  the  number  of  Private 
Branch  Exchanges  (PBX's)  with  digital  capable  microwave, 
optical  fiber,  or  copper  T-carrier  direct  tie-lines  to  tell 
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or  tandem  switches  with  direct  access  to  the  digital  tack- 
hone  system.  This  data  can  be  expressed  as  a  number  of  tie¬ 
lines  installed  or  as  a  percentage  of  installed  PBX's  with 
the  tie-lines.  This  is  an  indicator  that  network  users  want 
to  bypass  the  local  distribution  systems  which  are  difficult 
to  use  for  high  speed  digital  communications.  The  number  of 
PBX’s  with  tie-lines  can  be  entered  into  the  database  of  the 
DS3 .  A  forecast  can  be  generated  of  this  data  by  extrapo¬ 
lating  along  the  growth  curve  with  the  best  fit  to  the  data. 
This  curve  fitting  is  performed  by  the  DSS  and  the  results 
of  the  forecast  are  stored  in  the  DSS  database  for  later 
comparison  and  are  also  presented  to  the  user  in  either 
tabular  cr  graphical  form. 

The  above  example  is  one  of  an  accelerator  for  techno¬ 
logical  growth  of  ISDN  architectures.  It  would  also  be 
desirable  to  forecast  constraints  on  the  development  and 
implementation  of  this  technology.  The  number  of  engineers 
and  maintenance  perscrnel  trained  to  install  and  maintain  an 
ISDN  is  a  definite  constraint  on  implementation  of  an  ISDN 
architecture  in  the  United  States.  The  data  on  the  nunmer  of 
such  ISDN  trained  personnel  can  be  collected  and  forecast 
using  the  DSS. 

After  a  number  of  accelerators  and  constraints  have  been 
collected,  a  cross  impact  analysis  of  the  factors  upon  each 
other  can  be  performed  by  the  DSS.  An  analysis  of  this  type 
could  demonstrate  the  relative  impact  of  different  variables 
upon  each  other  to  obtain  an  approximation  of  the  relative 
time  required  to  achieve  a  desired  result.  For  example,  the 
impacts  cf  digital  communication  media  cost,  the  number  of 
ISDN  trained  personnel,  and  the  competition  to  provide 
digital  services  upon  ISDN  technology  growth  can  be  modeled. 
The  DSS  is  executed  with  the  impacts  as  subjective  values 
and  are  defined  as  desirable  or  negative  impacts  upon  ISDN 
technology. 
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An  example  cross  impact  matrix  is  given  in  Table  7.  The 
variables  listed  in  the  table  are: 

1.  Digital  communications  media  cost  =  '  M  ’ 

2.  Number  of  ISDN  trained  personnel  =  ’P* 

3.  Competition  to  provide  digital  services  =  'C' 

4.  Growth  rate  of  ISDN  technology  =  '3* 

The  cross  impact  matrix  indicates  that  the  cost  of  communi¬ 
cations  impacts  negatively  on  the  rate  of  growth,  while  the 
training  of  more  personnel  facilitates  the  training  of  even 
more  personnel.  The  advantage  of  this  model  is  that  it 
demonstrates  the  relative  impact  that  a  combination  of  vari¬ 
ables  can  have  on  the  growth  rates  of  other  variables. 
Figure  6.1  is  the  result  of  executing  the  model  with  the 
values  from  the  cross  impact  matrix  of  Table  7. 
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Cross  Impact  Matrix 
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Figure  6. 1  Output  of  Cross  Impact  Analysis. 


▼II.  CONCLUSIONS 


The  National  Communications  System  has  been  tasked  with 
the  overall  responsibility  for  planning  a  national  security/ 
emergency  preparedness  telecommunications  system  [Ref.  17]. 
An  automated  decision  support  system  which  can  aid  NCS 
managers  in  making  effective  forecasts  of  telecommunications 
technology,  prices  and  costs  would  be  an  invaluable  tool  for 
the  conduct  of  this  planning.  This  work  has  described  the 
logical  design  of  such  a  system.  The  design  is  general 
enough  to  allow  maximum  flexibility  in  the  eventual  conver¬ 
sion  to  a  physical,  coded  implementation.  It  will  not  be 
difficult  to  code  this  design  in  a  higher  order  language 
such  as  Ada,  COBOL,  or  BASIC.  More  importantly,  the  logical 
design  cf  this  DSS  lends  itself  toward  implementation 
utilizing  a  fourth  generation  language  such  as  FOCUS  or 
NOMAD.  The  ability  of  these  type  of  packages  to  access  data 
through  a  database-  type  format  allows  a  non-programmer  to 
take  this  design  and  create  a  database  which  can  be  accessed 
by  simple  routines  written  in  the  generic  language  which 
accompanies  these  packages. 

Furthermore,  the  design  of  this  forecast  DSS  can  be 
implemented  on  any  size  computer  from  a  desktop  microcom¬ 
puter  up  to  a  large  mainframe.  The  designation  cf  a 
specific  system  to  run  this  package  at  this  stage  of  the 
design  is  not  necessary  nor  is  it  desirable.  The  end  product 
that  a  user  should  be  looking  for  is  an  acceptable  logical 
design,  not  an  up  and  running  system.  With  a  logical  design 
the  user  can  change  computer  systems  without  having  to  have 
all  of  his  software  redesigned.  It  will  be  simple  to  have  it 
coded  for  the  new  system  or  implement  it  himself  with  a 
fourth  generation  package  as  described  earlier. 
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The  nodular  design  of  this  system  enables  expansion  of 
the  forecast  routines  with  little  effort.  The  models 
selected  for  this  design  were  chosen  for  their  simplicity 
and  ease  of  understanding  by  the  user.  A  complex  econometric 
model  may  be  more  accurate  (though  that  has  been  debated  by 
professionals  in  the  field  [Ref.  18]  ),  but  the  simplicity 
of  simple  regression  models  is  more  intuitive  to  the 
manager.  Two  possible  simple  models  could  be  added,  an  expo¬ 
nential  smoothing  model,  and  a  moving  average  model.  However 
the  seasonal  or  normalizing  techniques  which  accompany  these 
models  are  not  so  simple  and  depend  on  many  more  assumptions 
than  a  simple  regression  extrapolation.  Through  the  use  of 
the  scoring  model  construction  technique,  the  manager  can 
build  simple  multivariable  bootstrap  models.  Su^n  models 
have  been  shown  to  model  reality  to  a  remarkable  degree 
[Ref.  18].  In  any  case,  this  system's  strict  adherence  to 
structured  techniques  and  modularity  would  facilitate  any 
future  modification  or  expansion  brought  about  by  the 
dynamic  nature  of  the  telecommunications  environment  and  the 
possibility  of  changes  in  overall  system  requirements. 
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APPINDII  A. 

ESSENTIALS  OF  STBOCTURED  DESIGN 


Stevens  et  al.  [Ref.  19]  introduced  the  concept  of 
structured  design  as  a  comprehensive  method  for  reducing  the 
growing  complexity  of  program  design.  Because  it  is  not  a 
true  methodology,  it  is  used  most  effectively  in  consonance 
with  other  techniques,  such  as  structured  programming, 
structured  analysis,  and  HIPO  hierarchy  charts.  The  key  to 
structured  design  is  reducing  the  logical  view  of  the  system 
into  simple  pieces,  called  modules,  that  can  be  readily 
understood  and  hence  constructed.  The  rationale  behind  this 
concept,  common  with  most  modern  software  design  techniques, 
lies  with  principles  of  behavioral  science  regarding  the 
human  ability  to  comprehend  and  solve  problems  faster  when 
they  are  of  manageable  size  and  complexity.  These  princi¬ 
ples  were  the  basis  for  top-down  design,  which  calls  for 
decomposing  large,  complex  problems  into  smaller,  less 
complex  problems,  until  the  original  problem  has  been 
expressed  as  a  combination  of  many,  small,  solvable  prob¬ 
lems.  However,  top-down  design  alone  is  not  sufficient  for 
ensuring  modules  that  are  easy  to  maintain  and  modify. 
Structured  design  includes  the  concept  of  top-down  design, 
along  with  ether  strategies  and  heuristics.  Among  these  are 
coupling  and  cohesion. 

Coupling  is  a  measure  of  the  strength  of  association 
between  separate  modules  within  a  system.  The  greater  the 
degree  of  coupling,  the  harder  it  is  to  understand,  change, 
or  correct  a  module  and  hence  the  more  complex  and  compli¬ 
cated  the  system.  One  goal  of  structured  design  is  to 
create  modules  with  coupling  as  weak  as  possible.  This  can 
be  achieved,  at  least  in  theory,  by  designing  the  module 
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interface  to  be  simple  and  obvious  and  ensuring  the  connec¬ 
tion  between  modules  is  to  the  normal  module  int<  .face  (the 
entry  point)  rather  than  to  module  internal  components.  j 

Modules  share  a  common  environment  when  they  interface  ! 

with  the  same  storage  area,  data  region  or  device.  Ccmmon  ■ 

environments  often  provide  complex  paths  along  which  errors  j 

can  travel  when  a  change  is  made  to  one  module.  When  ccmmon 
environments  are  originally  designed  into  a  system,  add-on 
modules  will  also  be  forced  to  interface  via  the  common 
environment,  further  degrading  the  product.  Limiting  ccmmon 
environment  access  to  the  smallest  possible  subset  of 
modules  tends  to  minimize  this  potential  problem.  Another 
method  to  achieve  lew  coupling  is  to  restrict  interface 
connections  to  obvious  relationships  and  avoid  those  that 
are  inferred.  Thus,  connections  which  refer  to  a  module  as 
a  whole  require  less  coupling  than  those  which  refer  to  an 
internal  component  of  a  module.  This  latter  case  is  called 
pathological  connection,  and  is  one  of  the  strongest  forms 
of  coupling  between  modules.  It  can  be  avoided  by  ensuring 
a  subroutine  executes  only  when  it  is  called  formally  by  a 
module,  it  operates  strictly  on  data  passed  by  the  calling 
module,  only  that  data  essential  to  the  performance  of  its 
task  is  passed  to  the  subroutine,  and  all  results  of  its 
operations  are  returned  to  the  calling  module. 

Cohesion  is  defined  as  the  strength  of  association  of 
the  elements  within  a  module,  and  is  measured  by  a  term 
called  binding.  The  goal  is  to  strive  for  high  binding, 
which  directly  results  in  reduced  coupling  by  minimizing  the 
relationships  among  modules.  The  levels  of  cohesion  may  be 
addressed  separately,  scaled  from  low  to  high,  and  although 
a  module  may  exhibit  multiple  levels  of  binding,  the  highest 
■-hat  may  be  applied  determines  the  module  level. 

1.  Coincidental  binding  means  there  is  no  meaningful 
relationship  among  the  internal  elements  of  a  module. 
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It  usually  st€ns  from  haphazard  attempts  at  breaking 
code  up  into  "modules"  or  consolidating  duplicate 
ceding  from  several  modules  into  one  "module". 

2.  Logical  binding  means  there  exists  some  kind  of 
logical  r elaticnship  among  the  elements  of  a  module. 
It  often  results  from  "cute",  difficult  to  modify, 
shared  code,  or  from  passing  unnecessary  arguments. 

3.  Temporal  binding  mans  the  elements  are  logically 
related  also  in  time.  Such  elements  are  executed 
during  a  common  period  of  time.  The  reason  such 
modules  are  higher  on  the  cohesion  scale  is  that  all 
the  elements  are  at  least  executed  at  once. 

4.  Communicational  binding  means  that  elements  are 
related  further  to  the  same  input/output  data  set. 

5.  Sequential  binding  means  that  elements  within  a 
module  are  processed  sequentially.  It  usually 
results  from  literal  transformation  of  flowchart 
procedural  blocks  to  modules.  However,  procedural 
processes  can  encompass  more  than  one  function. 

6.  Functional  binding  means  all  the  elements  of  a  module 
are  related  to  the  performance  of  a  single  function. 
It  is  the  strongest  level  of  binding.  In  practice, 
the  determination  of  what  exactly  constitutes  a  func¬ 
tion  is  a  difficult  task,  further  compounded  by  the 
dilemma  of  deciding  how  far  to  divide  functionally 
bound  subfunctions. 

Although  there  may  well  be  a  basic  tradeoff  to  be 
confronted  between  "structural  design"  modules  and 
execution/memory  overhead,  there  are  a  number  of  reasons  why 
a  structured  design  may,  indeed,  enhance  execution  time/ 
memory  space  required.  The  major  reasons  are: 

1.  Error  modules  (called  "optional")  may  never  be  called 
from  memory. 
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2.  Other,  well- designed  modules  may  only  be  executed  a 
minimum  number  of  times. 

3.  Structured  design  reduces  the  amount  of  duplicate  or 
redundant  code. 

The  structured  design  process  is  divided  into  two 
phases:  general  program  design  and  detailed  design.  General 
program  design  is  described  as  deciding  what  the  program 
functions  will  be,  and  detailed  design  as  deciding  how  the 
functions  will  be  implemented.  The  overall  design  goal 
remains  the  structure  of  functionally  bound,  simply 
connected  modules.  The  technique  is  simply  top-down, 
modular,  hierarchical  with  a  unique  graphical  format.  The 
following  guidelines  may  be  helpful  when  utilizing  the 
structured  design  process: 

1.  In  crier  to  enhance  maintainability,  ensure  the 
structure  of  the  design  matches  the  structure  of  the 
problem.  Subsequent  changes  to  the  problem  will  then 
affect  a  minimal  number  of  modules. 

2.  Strive  for  simple  designs  where  the  scope  of  effect 

of  a  decision  is  restricted  to  the  scope  cf  ccntrol 
of  the  module  containing  the  decision.  This  is 
accomplished  by  either  moving  the  decision  element  up 
in  the  otructure  chart,  or  by  moving  the  entire 

module  containing  the  decision  so  that  it  falls 

within  the  scope  of  control. 

3.  Use  nodule  size  as  an  indicator  of  potential  prob¬ 
lems.  A  module  that  is  extremely  small  may  not 

perform  a  complete  function.  A  module  that  is 
extremely  large  may  include  more  than  one  function. 

4.  It  is  acceptable  to  design  modules  that  return  binary 
error  or  end-cf-file  flags.  However,  the  same  module 
should  not  be  concerned  with  error  recovery. 

5.  Duplicate  code  may,  under  certain  circumst ances ,  be 
acceptable.  Euplicate  functions,  however,  should  be 
eliminated. 
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6.  Particular  data  structures  should  be  isolated  in  a 
minimum  number  of  modules.  This  will  facilitate 
module  changes  due  to  subsequent  alterations  in  that 
data  structure’s  specifications. 

7.  Minimize  the  number  of  parameters  passed  between 
modules.  The  goal  is  tc  pass  only  that  data  required 
by  the  module  to  accomplish  its  function. 

There  are  several  important  variations  of  the  basic 
structured  design  methodology.  DeMarco  [Ref.  12]  proposes 
an  approach  that  begins  with  the  codification  of  the  func¬ 
tional  specification,  or  translating  the  prose  specification 
into  working  fixed-format  documents  (data  flow  diagrams, 
data  dictionary,  transform  descriptions,  data  structure 
chart).  This  step  cculd  actually  be  considered  "structured 
analysis".  The  next  step  is  the  derivation  of  the  structure 
chart,  a  modular  hierarchy  chart  which  records  major  design 
decisions  and  philosophy.  Structure  charts  are  rec cm  mended 
rather  than  flowcharts  because  flowcharts  violate  the  prin¬ 
ciple  of  information  hiding  by  exposing  critical  design 
decisions  too  early  in  the  design  process  (for  example,  in 
what  order  and  under  what  conditions  functions  are 
performed) .  Additionally,  structure  charts  depict  module 
connections  and  calling  parameters,  are  smaller  in  size  and 
generally  more  manageable.  In  the  DeMarco  version  module 
design  occurs  next  through  construction  of  module  descrip¬ 
tions.  The  final  step  is  packaging  the  design,  or  shaping 
the  logical  design  to  accommodate  the  physical  environment 
(machine,  operating  system,  coding  language,  memory  limita¬ 
tions,  time  restrictions).  The  key  is  to  construct  an 
environment-independent  design  first,  maximizing  cohesion 
and  minimizing  coupling,  then  impose  packaging  constraints 
so  as  tc  minimize  degradation  of  product  quality.  An  impor¬ 
tant  structured  design  principle  is  to  delay  packaging  as 
long  as  possible  in  crder  to  "hide"  the  significant  nature 
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************************************************************ 
4. 1.4.2  CALCULATE  MODEL  SCORE 


Inpats : 
Outputs 


MODEL  STRUCTURE 
AVG_V5LUE 

MCDEL  SCORE 


Source:  Process  4.1.4.  1 
Process  4. 1 . 4.  1 

Destination:  Process  4.  1.4.1 


A.  For  Each  GROUP 

S.  If  GROUP  LEVEL  =  1 

C.  For  each  SUE  GROUP 

D.  Sum  the  vllue  of  the  AVG  VALUES  multiplied  by 

the  FACTOR  WEIGHT  of-each  FACTOR  ID 

E.  Multiply  this  sum  by  the  SUB  GROUP  WEIGHT 

F.  Remember  this  as  the  SUB  GROUP  VALUE 

G.  End  For 

H.  Multiply  the  SUB  GROUP  VALUES  together 

I.  Multiply  the  SUB- GROUP- VALUE  by  the 

GROUP  WEIGHT- 

J.  Remember  this  as  the  GROUP  VALUE 

K.  End  If. 

L.  End  For. 

M.  If  there  are  2  groups  with  a  GROUP  LEVEL  =  1  then 

N.  DIVIDE  THE  GROUP  VALUE  of  the  GEOUP  which  has  a 

GROUP  TYPE  =-"Desirable"  by  the  GROUP  VALUE 
of  the  GROUP  which  has  GROUP  TYPE  equal  to 
"Undesirable" 

C.  Remember  this  number  as  MODEL  SCORE 

F.  End  If 

£.  For  each  GROUP 

R.  If  GROUP  LEVEL  =  0 

S.  GFOU P— V ALU  E  =  AVG  VALUE  *  GROUP  WEIGHT 

T.  Multiply  the  GROUP  VALUE  times  The  MODEL_SCORE 

U.  Remember  this  result  as  the  MODEL  SCORE 

V.  End  If. 

W.  End  For. 


TABLE  20 

Process  4. 1.4. 2  Basis  Paths 


Complexity  Metric:  7 

1  .  almpqw 

2.  abklmpgw 

3.  atcghigklmpqv 

4.  atcaefghi jRlmpgw 

5.  almnopgw 

6.  almpqrvw 

7.  almpgrstuvw 
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************************************************************ 
4.  1.  4. 1  SCORING  MODEL 


Inputs:  MODEL  LIMIT 

MODEL-STRUCTURE 
FACTOR  VIEW 
MODEL_SCORE 

Outputs:  MODEL  STRUCTURE 
AVG  VALUE 
MODEL  VIEW 


Source:  Process  4.1.2 
Process  4.  1 .  i 
Process  4.1.3 
Process  4. 1 . 4. 2 

Destination:  Process  4. 1.4.2 
Process  4. 1.4.2 
Process  4. 3 


A.  INTERVAL  NUMBER  =  1 

B.  While  INTERVAL  NUMBER  <=  LAST  OBSERVED  INTERVAL 

C.  GCOD_INTER VIL  =1 

D.  For  each  FACTCF  ID  in  model 

E.  If  OBSERVED  =  0  then 

F.  GOOD  INTERVAL  =  0 

G.  End  If.“ 

H.  End  For. 

I.  If  GOOD  INTERVAL  =  1  then 

J.  Do  CALCULATE  MODEL  SCORE 

K.  OBSERVE  =  1 

Else 

L.  OBSERVE  =  0 

M.  MODEL  SCORE  =  0 

N.  End  If.  ~ 

C.  INTERVAL  NUMBER  =  INTERVAL  NUMBER  +  1 

P.  End  While  " 

C.  Combine  data  into  MODEL_VIEW 


! - 1 


TABLE  19 

Process  4. 1.4.1  Basis  Paths 


Complexity  Metric:  5 

1.  dlpg 

2.  atcdhilmnopg 

3.  atcdeghilmnopg 

4.  atcderghilmnopg 

5.  atcdefghi jknopg 


80 


mo^Tji-nno  sj> 


************************************************************ 
4.1.3  SCREEN  FACTOR  VALUES 

Inputs:  EARE  FACTOR  VIEW  Source:  Process  4.1.1 
EL EMENT_ VALUE  FACTOR  File 

Outputs:  FACTOR  VIEW  Destination:  Process  4.1.4 

FACTO R  — VI EW  Process  4.3 


.  For  each  INTERVAL  NUMBER 

.  If  CATE  OF  OBSERVATION  is  greater  than  or  equal 
to  BEGIN  INTERVAL (INTERVAL  NUMBER)  and  less 
than  END“INTERVAL jlNTERVAL-NUMBSR)  then 
TOTAL  =  TUTAI  +  ELEMENT  VALUE 
OBSERVED  =  CESERVED  +  1" 

LAST  OBSERVED  INTERVAL  =  INTERVAL  NUMBER 
.  End  If. 

A VG_VALUE  =  TOTAL  /  OBSERVED 
.  End  For. 


********************44*******************? 

4.  1.2.2  CALCULATE  MCDSL  LIMIT 


4‘4'4‘4‘4‘4‘4’M‘4:4>4^4<4'£ 


Inputs: 

Outputs 


MODEL  STRUCTURE 
FACTOR_LIMIT 

MODEL  LIMIT 


Source:  Process  4. 1.2.1 
Process  4. 1 . 2.  1 

Destination:  Process  4.1.4 


A.  For  Each  GROUP 

B.  If  GROUP  LEVEL  =  1 

C.  For  each  SUB_GROUP 

D.  Sum  the  value  of  the  FACTOR  LIMITS  multiplied 

by  the  FACTOR  WEIGHTS  of  each  FACTOR  ID 

E.  Multiply  this  sum  By  the  SUB  GROUP  WEIGHT' 

F.  Remember  this  as  the  SUB  GROUP  VALUE 

G.  End  For 

H.  Multiply  the  SUB  GROUP  VALUES  together 

I.  Multiply  the  SUB'G RO UP'VA LUE  bv  the 

GROUP  WEIGHT- 

J.  Remember  this  as  the  GROUP  VAL 

K.  End  If. 

L.  End  For. 

M.  If  there  are  2  groups  with  a  GROUP  LEVEL  =  1  then 

N.  DIVIDE  THE  GROUP  VALUE  of  the  GROUP  which  has  a 

GROUP  TYPE  =“"Desir able"  by  the  GROUP  VALUE 
of  the  GROUP  which  has  GROUP  TYPE  equal  to 
"Undesirable" 

O.  Remember  this  number  as  MODEL  LIMIT 

F.  End  If 

Q.  For  each  GROUP 

R.  If  GROUP  LEVEL  =  0 

S.  GROUP- VALU E  =  FACTOR  LIMIT  *  GROUP  WEIGHT 

T.  Multiply  the  GROUP  VALUE  times  t  he- MODEL  LIMIT 

U.  Remember  this  result  as  the  MODEL  LIMIT  - 

V.  End  If. 

W.  End  For. 


TABLE  17 


;cess  4. 1.2.  2  Basis  Paths 


Complexity  Metric:  7 

1.  almpgw 

2.  almpgrvw 

3.  abklmpgw 

4.  almpqrstuvw 

5.  atcghijklmpqw 

6.  abcdefghi jRlmpgw 

7.  almnopqw 
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****  *  **  *******  ******************************* *************** 
4. 1.2.1  CHECK  FCE  MODEL  LIMIT 

Inputs:  MODEL  STRUCTURE  Source:  Process  4.1.1 

FACTOE_LIMIT  Process  4.1.1 

Outputs:  M0DEL_LIMIT  Destination:  Process  4.1.4 


.  for  each  FACTOR  IE  in  MODEL  STRUCTURE 
If  FACTOR  LIHIT  =  Null  tHen 
MODEL  LIMIT  =  Null 
End  If.  ~ 

End  For. 

If  MODEL  LIMIT  <>  Null  then 
Do  CALCULATE  MCDEL  LIMIT 
End  If. 


TABLE  16 

Process  4.1.2.  1  Basis  Paths 

Complexity  Metric:  4 

1.  aefh 

2.  atdefh 

3.  atcdefh 

4.  atcdefgh 


********************4  *************************************** 


4.  1.  1  LIMIT  CHOICES 

Inputs:  FIRM  SELECT 

MODEr  STRUCTURE 
FACTOH_LIMIT 

Outputs:  EARE  FACTOR  VIEW 
B AF  E— FACTOR “VIEW 
MCDEr  STRUCTURE 
MCDEL“STRUCTURE 


Source:  Process  2 

MODEL  STRUCTURE  File 
FACTO!  File 

Destination:  Process  4.1.3 
Process  4.1.2 
Process  4.1.2 
Process  4.1.4 


A.  INTERVAL  NUMBER  =  0 

B.  END  INTEFVALJO)  =  BEGIN  PERIOD 

C.  While  END  INTERVAL (INTERVAL  NUMBER)  <  END  PERIOD 

D.  INTERVAL  NUMBER  =  INTERVAL  NUMBER  +  1  “ 

E.  BEGIN  INTERVAL  (INTERVAL  NUflBER)  = 

END  INTERV  AL "(INTERVAL  NUMBER  -  1) 

F.  END  INTERVAL  {INTERVAL  NUMBER)  =  “ 

BEGIN_INTE!VAL  (INTERVAL  NUMBER)  ♦  INTERVAL 

G.  End  While. 

H.  LAST  INTERVAL  =  INTERVAL  NUMBER 

I.  If  MCDEL_ID  is  in  FIRM_SELECT  and  CHOICE  =  "Forecast" 

then 

J.  For  each  FACTCR  ID  in  MODEL  STRUCTURE 

K.  Do  SCREEN  FACTOR  VALUES  “ 

L.  End  For. 

M.  Do  CALCULATE  KCDEL  LIMIT 

N.  INTERVAL  NUMBER  =  1 

O.  While  INTERVAL  NUMBER  <=  LAST  OBSERVED  INTERVAL 

P.  Do  SCORING  ‘fiODEL 

Q.  INTER  VAL_N  UMBER  =  INTERVAL  NUMBER  +  1 

R.  End  While. 

S.  End  If. 


TABLE  15 

Process  4.1.1  Basis  Paths 


Conplexity  Metric:  5 

1.  atcdefghis 

2.  atcghis 

3.  atcghi jlmnors 

4.  atcghigklmncrs 

5.  atcghij lmnopgrs 
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************************************************************ 
3.0  ELEMENT  ENTRY 


Inputs:  FACTOR  ID 

CATE  07  OBSERVATION 
E1EMENT“S0URCE 
ELEMENT“VALUE 
DATE  OF- ENTR Y 
UNITE  “ 

Outputs:  ELEMENT  ENTRY 
ENTRY  SCREEN 


Source:  Operator 
Operator 
Operator 
Operator 
Calen  dar 
FACTOR  File 

Destination:  FACTOR  File 
Operator 


.  If  FACTOR  ID  is  in  FACTOR  File  then 
Displa?  ENTRY  SCREEN 
Enter  DATE  OF- CESER VATIO N 
Enter  ELEMENT“SCURCE 
Enter  ELEMENT- VALUE 
ELEMENT  ANALYSIS  =  "Historical'* 

Combine-with  DATE  OF  ENTRY  and  store  in  FACTOR  File 
End  If  - 


TABLE  14 

Process  3.0  Basis  Paths 

Complexity  Metric:  2 

1.  ah 

2.  atcdefgh 


TABLE  12 

Process  2.2  Basis  Paths 


Complexity  Metric:  7 

1 .  alct 

2.  aldeqh j kmnpgst 

3.  afcdefqh jkmnpgst 

4.  abdeghi  ikmnpgst 

5.  aldeghj klmnpgst 

6.  abdeghj kmnopqst 

7.  aldeghj kmnpgrst 


***************************  *********** ******* *************** 


2.3  ENSURE  SUFFICIENT  DATA  AVAILABLE 

Inputs:  FIRM  SELECT  Source: 

FACTOR 
FACTOR  ID 


Process  2. 1 
FACTOR  File 
Process  2.  1 


Outputs:  VALIDATION 


Destination:  Process  2.  1 


A.  If  CHOICE  =  "Monte  Carlo"  cr  "Forecast"  and  at 
least  three  ELEMENT  ENTRYs  with  an 
ELEMENT  ANALYSIS  equal  to  "Historical" 
are  NOT~present  with  DATE  OF  OBSERVATION 
between  BEGIN  EERIOD  and  "END” PER IOD  then 
E.  VALIDATION  =  "Not  Valid" 

C.  End  If. 


TABLE  13 

Process  2.3  Basis  Paths 

Complexity  Metric:  2 

1 .  ale 

2.  ac 
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TABLE  11 

Process  2. 1  Basis  Paths 


Complexity  Metric:  7 

1 .  aler 

2.  atcder 

3.  afgr 

4.  afghjkpgr 

5.  afghiikpqr 

6.  afghiklmnopqr 

7.  afgh jklmopqr 


*************************** ******************** ************ 

2.2  SET  DEFAULT  VALUES 

Inputs:  USER  SELECT  Source:  Process  2. 1 

TODAYS  DATE  Calendar 

MODEL_5TRUCTORE  MODE L_STROCTURE  Eile 

Outputs:  FIRM_S ELECT  Destination:  Process  2.1 


A. 

E. 

C. 


VALIDATION  =  "Valid" 

If  IDENTIFICATION  =  MODEL  ID  and  MODEL  ID  is  not  in  the 
MODEL  STRUCTURE  File  fhen 
VALIDATION  =  "Net  Valid" 

Else 

Get  TODAYS  DATE 

If  BEGIN  PERIOD  =  Null  then 

BEGIN- PERIO E  =  TODAYS  DATE  -  15yrs 
End  If.  - 

If  END  PERIOD  =  Null  then 

END- P  ERIOD  =  TODAYS  DATE  ♦  15yrs 
End  If 7 

If  BEGIN  PERIOD  >=  END  PERIOD  then 
Selection  is  not  valid 
End  If. 

If  INTERVAL  =  Null  then 
INTERVAL  =  lyr 
End  If. 

If  CHOICE  =  "Mcnte  Carlo"  and  ITERATIONS  =  Null  then 
ITERATIONS  =  100 
End  If. 
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TABLE  10 

Process  1.3  Basis  Paths 


P 

rv 
r. . 

a 


Complexity  Metric:  5 


3.  aicdfgnijp 

4.  afcghigklmnop 

5.  alghijklmop 


************************************************************ 

2.1  MCDE1  VALIDATION 


Inputs:  USEE  SELECT 

USER-SELECT 
MODEL  STRUCTURE 
FIRM  SELECT 
VALIDATION 


Source:  Manager 

Process  6 
Process  2.2 
Process  2.2 
Process  2.3 


Outputs:  FIRM  SELECT 
F IRM“ SELECT 
FIRM~SELECT 
FACTOR  ID 


Destination:  Process  4 
Process  6 
Process  2.2 
Process  5 


A. 


If  a  FACTOR  ID  is  in  the  USER  SELECT  and  CHOICE  equals 
"Forecast"  then 

If  FACTOR  ID  is  present  in  the  FACTOR  File  then 
Do  SET“DEFAaLTS 

Do  ENSURE  SUFFICIENT  DATA  AVAILABLE 
End  If. 

Else 

If  a  MODEL  ID  is  in  the  USER  SELECT  then 
Do  SET  DEFAULTS 

If  CHOICE  =  "Cross  Impact"  then 
VALIDATION  =  "Not  Valid" 

End  If. 

If  VALIDATION  =  "Valid"  then 

Get  the  FACTOR  IDs  from  the  MODEL  STRUCTURE 
For  each  FACTOH  ID 

Do  ENSURE  SUTFICIENT  DATA  AVAILABLE 
End  For 
End  If. 

End  If. 

End  If. 
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TABLE  9 

Process  1.2  Basis  Paths 


Complexity  Metric:  2 

1 .  abcdi 

2.  abefghi 


********  ***********  ***********  ****************************** 

1.3  ADDITION  TO  FACTOR  FILE 

Inputs:  FACTOR  ID  Source:  Process  1.2 
FACTOR-  Manager 

Outputs:  FACTOR  Destination:  FACTOR  File  j 


A.  Che<?k  the  FACTOR  IE  against  the  FACTOR  File 
E.  If  it  is  not  present  then 

C.  Get  the  FACTOR  ID  along  with  the  FACTOR  TYPE 
and  CHARACTERISTIC  from  Manager 
If  the  FACTOR  TYPE  =  "Objective"  then 

Get  the  [J  NT  IS  and  the  FACTOR  LIMIT  from  Manager 
End  If  - 

End  If 

Get  FACTOR  IMPACT  of  the  FACTOR  upon  itself 
Get  FACTOR- IMPACT  of  the  OUTSIDE  WORLD  upon  the  FACTOR 
If  there  are  FACTORS  which  impact  on  this  FACTOR  then 
Provide  the  FACTOR  IDs 
Do  ADDITION  TO  FACTOR  FIIE 
If  these  impacting  FACTOR  IDs  are  not  already  I 

listed  in  the  FACTOR  File  as  impacting  on  the 
object  FACTOR  then 

.  Get  the  subjective  FACTOR  IMPACT 

End  If 

.  End  If 

_  i 


TABLE  8 

Process  1. 1  Basis  Paths 


Complexity  Metric:  7 

1  alcfgrsxyz 

2  abcdefgrsxyz 

3  atcf ghi jklqrsxyz 
h  ahcf ghmnpqrsxyz 

5  alcfghmopqrsxyz 

6  alcfghmopgrstwxyz 

7  alcf ghmopqrstuvvxyz 


************************************************************ 

1.2  SUB  GROUP  ORGANIZATION 


Inputs:  FACTOR  ID 

SOB  GROUP  ID 
SUB- GROUP- HEIGHT 
FACTOR_WETGHT 

Outputs:  SUB  GROUP 
FACTOR  ID 


Source:  Process  1.1 
Manager 
Manager 
Manager 

Destination:  Process  1.1 
Process  1.3 


A.  Do  ADDITION  TO  FACTOR  File 

E.  If  FACTORS  can  be  traded  off  against  FACTORS  in 
a  SU3_GROUP  then 

C.  Assign  FACTOR  tc  that  same  SUB  GROUP. 

D.  Assign  a  FACTOR  HEIGHT 

Else 

E.  Assign  FACTOR  as  sole  member  of  a  new  SUB  GROUP. 

F.  Assign  a  FACTOR  HEIGHT 

G.  Assign  a  SUB  GFTUP  ID. 

H.  Assign  a  subjective  SUB  GROUP  WEIGHT. 

I.  End  If  - 
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APPENDIX  B 

PROCESS  MIHI-S PECIFICATIONS 


************************************************************ 

1.  1  SCORING  MODEL  CO  NS  TR  UCTION 


Inputs:  MODEL  ID 

GROUP- 
FACTOR  ID 
SUB_GROUP 

Outputs:  MODEL_STRUCTURE 
FACTOR  ID 


Source:  Manager 

Manager 
Manager 
?  rocess  1 . 2 

Destination:  MODEL  STRUCTURE 

File 

Process  1.2 


Identify  F ACTOR_ 
technology  pe 
Eliminate  overla 
measure  the 
For  each  FACTOR 
Do  SU3_GROUP~ 
End  For. 

For  each  SUB  GRO 
If  each  SUB_G 
it  must  b 
zero  then 
Assign  thi 
Assign  thi 
Assign  a  G 
Assign  a  G 
Else 

If  SUB  GRO 
Assign 
Else 

Assign 
End  If 
End  If 
End  For 

For  each  GROUP 
If  GROUP_TYP E 
Assign  a  G 
Assign  a  G 
End  If 
End  For 

Assign  each  GROU 
Assign  the  model 


IDs  that  relate  to  how  well  the 
rforms. 

ys  of  ELEMENTS  from  the  model  that 
same  or  very  similar  characteristics. 

IE  in  the  model 
ORGANIZATION 

UP  ID 

FCUP  is  of  such  an  overriding  nature  that 
e  present  or  the  score  of  the  model  equals 

s  SUB  GROUP  to  be  the  sole  member  of  a  GROJ  P 
s  GROUP  a  GROUP  ID 
FCUP  LEVEL  =  0  ” 

RCUP~TYPE  =  "Override" 

UP  is  desirable  then 

to  a  GROUP  with  GROUP_TY PE  =  "Desirable" 
to  a  GROUP  with  GROUP  TYPE  =  "Undesirable". 


is  not  equal  to  "Override"  then 
FCUP  ID. 

FCUP-LE VEL  =  1. 


F  a  subjective  GROUP  WEIGHT, 
a  MODEL  ID. 


of  the  design  problem,  to  include  algorithms,  data  struc¬ 
tures  and  other  transformations. 

Enforcement  of  structured  design  techniques  should 
significantly  reduce  the  effort  required  for  program  modifi¬ 
cation  and  maintenance,  if  modules  possess  weak  coupling  and 
strong  cohesion.  Similarly,  modules  may  be  programmed, 
tested,  and  even  optimized  independently  using  these  tech¬ 
niques.  Structured  design  should,  as  a  minimum,  provide  for 
"predictable"  modules.  These  are  modules  which  perform 
identically  and  consistently  each  time  they  are  called, 
given  identical  inputs.  Predictable  modules  also  tend  to 
perform  independently  of  their  environment.  It  is  not 
clear,  however,  that  strict  adherence  to  structured  design 
will  ultimately  result  in  a  "library"  of  generalized, 
application-independent  modules  that  may  be  easily  config¬ 
ured  to  implement  any  sophisticated,  complex  system.  In  the 
final  analysis,  structured  design  is  a  method,  not  a  method¬ 
ology,  and  is  to  be  used  with  other  methods  and  tools  to 
facilitate  the  design  of  programs. 


4444444**4*4*444***4**4**********4*4444****4* 44 *4**4*44*444 

4.3.  1.1  INITIALIZE  FUNCTIONS 


Inputs:  MODEL  VIEW 
FACTOR-  VIEW 


Source:  Process  4.1 
Process  4.  1 


Outputs:  DATA  POINTS 
AVG  7ALUE 
END”I NTER  V  A  L 
CURVE 
LIMIT 


Destination:  Process  4.3.  1.3 
Process  4.3.  1.2 
Process  4.3.  1.2 
Process  4 . 3 . 1 . 2 
Process  4.3.  1.2 


A.  If  FACTOR  LIMIT  =  Null  then 

B.  PICK  =  Set  [' linear* f *  Log '  | ' Double-Log*  ] 

Else 

C.  PICK  =  Set  [ *  Pearl* I • Gompertz' 1 'Linear' | » Log’ | » Doulle-Lo g'  ] 

D.  LIMIT  =  FACTOR  LIMIT 

E.  End  If. 

F.  For  CURVE  =  FIRST'LAST  of  set  PICK 

G.  1  =  0 

H.  COUNT  =  1 

I.  While  COUNT  <=  LAST  OBSERVED  INTERVAL 

J.  If  OBSERVE  (COUNTf  >  0  then 

K.  1  =  1*1 

L.  Do  CURVE  FUNCTION 

M.  End  If 

N.  COUNT  =  COUNT  +  1 

C.  End  While. 

P.  DATA  POINTS  =  I 

C.  Do  CALCULATE  REGRESSION 

E.  End  For 
S.  Co  SELECT  CURVE 


TABLE  21 

Process  4.3. 1.1  Basis  Paths 


Complexity  Metric:  5 

1.  atefrs 

2.  acdefrs 

3.  atefghiopgrs 

4.  atefghi jmnopgrs 

5.  atefghi jklmnopgrs 
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************************************************************ 

4.3. 1.2  CALCULATE  CURVE  FUNCTIONS 


Inputs:  LIMIT 

AVG  VALUE 
END- INTERVAL 
CURVE 


Source:  Process  4.3.  1.1 
Process  4. 3 . 1 .  1 
Process  4. 3.  1 .  1 
Process  4 . 3  .  1 .  1 


Outputs:  DEPENDENT 
INDEPENDENT 


Destination:  Process  4.3. 1.3 
Process  4 . 3. 1 . 3 


A.  Choose  from  the  following: 

CURVE  =  Pearl 

DEPENDENT  =  LOG  (LIMIT  /  AVG  VALUE  -  1) 
INDEPENDENT  =  END_I NT  ERV  AL  - 
CURVE  =  Gompert2 

DEPENDENT  =  LOG  (LOG  (LIMIT  /  AVG  VALUE  )  ) 

INDEPENDENT  =  END  INTERVAL 
CURVE  =  Linear 

DEPENDENT  =  AVG  VALUE 
INDEPENDENT  =  END_INTER  VAL 
CURVE  =  Logarithmic 

DEPENDENT  =  LOG  (AVG  VALUE) 

INDEPENDENT  =  END  INTERVAL 
CURVE  =  Double  logarithmic 

DEPENDENT  =*10G  (AVG  VALUE) 

INDEPENDENT  =  LOG  (END  INTERVAL) 

End  Choice. 


TABLE  22 

Process  4.3. 1.4  Basis  Paths 


tc 


************************************************************ 
4.3. 1.3  CALCULATE  REGRESSION 

Inputs:  DEPENDENT  Source:  Process  4.3.  1.1 

DATA  POINTS  Process  4.3.  1.1 

INDEPENDENT  Process  4.3.  1.1 

LAST  OBSERVED  INTERVAL  Process  4.3. 1.1 


Outputs:  REGRESS  ANALYSIS 
REGRESS_ANALYSIS 
REGRESS“ANAIYSIS 
REGRESS“ANAIYSIS 
REGRESS-ANALYSIS 


A. 

B. 

C. 

D. 

E. 

F. 

G. 

H. 

I. 

J. 

K. 

L. 

M. 

N. 

O. 
P. 
Q- 

R. 

S. 

T. 

U. 

V. 

v. 

X. 

Y. 


Destination:  Process  4.3.2 
Process  4.3.3 
Process  4.  3.  4 
Process  4.3.5 
Process  4.3.6 


Define  Function  R 


For  I 
P  = 


=  1  to  LAST  0 


=  A  + 
SERVED 


i :  8 


DEPENDENT 
(DEPENDENT  ** 
INDEPENDENT 


B  *  z 
INTERVAL 


2) 


**  2) 

INDEPENDENT) 


/  SI 

*  Q  -  P  **  2)  ) 


S  =  S  +  (INDEPENT  T 
U  =  U  ♦  (DEPENDE  * 

End  For. 

SI  =  DATA  POINTS  *  R  **  2 

M2  =  R  /  UATA  POINT 
B  =  (DATA  POINTS  *  -  P  *  R) 

A  =  jP  -  B  *  R)  /  LATA  POINTS 
V  =  E  *  SQR  (SI  /  (DAT!  POINTS 
For  I  =  1  to  DATA  POINTS 

N  (I)  =  Fn  R  (INDEPENDENT) 

0(1)  =  DEPENDENT  -  N  (I) 

End  For. 

For  I  =  1  to  DATA  POINTS 
01  =  01  +  0(1)"**  2 
End  For. 

02  =  01  /  (DATA  ECINTS  -  2) 

C3  =  SCR  (02)  " 

B 1  =  (SQR  (DATA  ECINTS)  *  C3)  /  SQR 
VARIATE  =  0.688  fcr  a  5015  confidence 
Forecast  CURVE  with  highest  correlation 


(51) 

interval 

factor  =>  V 


CH  M  MODOZS  M  Wf-iHMO^IHO 


********************4***** ******************* *************** 


4.3.2  PEARL  CURVE  FORECAST 

Inputs:  VARIATE 

IDENTIFIER 
REGRESS  ANALYSIS 
FACTOR  VIEW 
MODEL_VlEW 

Outputs:  EXPANDED  MODEL  VIEW 
EXPAN DED— FACTOR  VIEW 
EXPANDED"FACTCR“VIEW 


Source:  Process  4.3.1 
Process  4.  3.  1 
Process  4.3.1 
Process  4.3.1 
Process  4.3.1 

Destination:  Manager 
Manager 
Process  4.3.1 


Define  Function  R  (Z)  =  A  +  B  *  Z 

Define  Function  P  Z)  =  LIMIT  /  n  *  EXP(Z)) 

Define  Function  F  (Z)  =  03  *  SQR  (1  *  1  / 

(DATA  POINTS  +  (DATA  POINTS 
*  (Z M2)  **  2)  /  SI ) ) 

Print  » A  =  •  ;EXP  (A) 

Print  ' B  =  '  :-B 

Print  ’Correlation  Coefficient  ='; COER  ELATION 
Print  'Standard  Error  of  B  =';B1 
INTERVAL  =  1 

While  INTERVAL  <=  LAST  OBSERVED  INTERVAL 

ESTIMATE  =  Function  P(  Function  R(  END  INTERVAL)  ) 
UPPER  =  ESTIMATE  +  (  VARIATE 

*  Function  F(  END  INTERVAL) 

LOWER  =  ESTIMATE  -  (  VARIATE 

*  Function  F(  END  INTERVAL) 

INTERVAL  =  INTERVAL  ♦  1  ~ 

End  While. 

INTERVAL  =  LAST  CESER7ED  INTERVAL  +  1 
While  INTERVAL  LAST  IUT ERV AL_NU MBEF. 

ESTIMATE  =  Function“P (  Function  R( 

UFPER  =  ESTIMATE  +  (  VARIATE 

*  Function  F (  END  INTERVAL) 

LOWER  =  ESTIMATE  -  (  VARIETE 

*  Function  F(  END  INTERVAL)  ) 

INTERVAL  =  INTERVAL  +  1  “ 

End  While. 


) 


) 


END_INTERVAL)  ) 

) 


TABLE  24 

Process  4.3.2  Basis  Paths 

Complexity  Metric:  3 

1 .  atcdef ghinopu 

2.  atcdefghi jklmncpu 

3.  atcdef ahinopgrstu 


*******$************$********♦*******#********#**********#** 
4.3.3  GCMPERTZ  CURVE  FORECAST 


Inputs;  VARIATE 

IDENTIFIER 
REGRESS  ANALYSIS 
FACTOR  VIEW 
MODEL  VIEW 


Source:  Process  4.3.1 
Process  4.3.1 
Process  4.3.1 
Process  4.3.1 
Process  4.3.1 


Outputs:  EXPANDED  MODEL  VIEW  Destination:  Manager 
EXP AND ED- FACTOR  VIEW  Manager 

EXPANDED- FACTOR” VIEW  Process  4.3.1 


A. 

B. 

C. 


D. 

E. 

F. 

G. 

H. 

I. 

J. 

K. 


M. 

N. 
C. 
P. 
C. 
R. 


U. 


Define 

Define 

Define 


Print 

Print 

Print 

Print 


Function 

Function 

Function 


II 

(Z 


EXP  (-EXP  (Z)  ) 

TS  +  (DATA  POINTS 
M2)  **  2)  /  51)  ) 


LJ  aj 

R  (1 

int: 


=' ; CORRELATION 


3  1 


A  +  B  * 

LIMIT  * 

03  *  S< 

(DATA  P( 

*  (Z-- 

•B  =  '  ;  EXP  (A) 

•K  =  •  :-B 

'Correlation  Coefficie^ 

'Standard  Error  of  K  = 

INTERVAL  =  1 

While  INTERVAL  <=  LAST  OBSEF.  £D  INTERVAL 

ESTIMATE  =  Function”G (  Function  R(  END  INTERVAL)  ) 
UPPER  =  ESTIMATE  +  (  VARIATE 

*  Function  F(  END  INTERVAL)  ) 

LCWEB  =  ESTIMATE  -  (  VARIITE 

*  Function  F(  END  INTERVAL)  ) 

INTERVAL  =  INTERVAL  +  1  ” 

End  While. 

INTERVAL  =  LAST  OBSERVED  INTERVAL  *  1 

While  INTERVAL  ?=  LAST  IT1T ERV AL_N UMBER 
ESTIMATE  =  Function”G (  Function  R( 

UPPER  =  ESTIMATE  +  (  VARIATE 

*  Function  F{  END  INTERVAL) 

LOWER  =  ESTIMATE  -  (  VARIlTE 

*  Function  F(  END  INTERVAL) 

INTERVAL  =  INTERVAL  «■  1  ” 

End  While. 


END_INTERV  AL)  ) 

) 

) 


TABLE  25 

Process  4.3.3  Basis  Paths 

Complexity  Metric:  3 

1.  atcdefghinopu 

2.  atcdefghi jklmnopu 

3.  atcdef ghinopgrstu 
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************************************************************ 
4.3.4  LINEAR  CURVE  FORECAST 


Inputs:  VARIATE 

IDENTIFIER 
REGRESS  ANALYSIS 
FACTOR  VIEW 
MODEL  VIEW 


Source:  Process  4.3.1 
Process  4.3.1 
Process  4.3.1 
Process  4.3.1 
Process  4.3.1 


Outputs:  EXPANDED  MODEL  VIEW  Destination:  Manager 
EXPAN DED“FACTOF  VIEW  Manager 

EXPANDED- FACT OR- VIEW  Process  4.3.1 


Define  Function  R(Z)  =  A  +  B  *  Z 

Define  Function  F  (Z)  =  03  *  SQR(1  ♦  1  / 

(DATA  POINTS  +  (DATA  PO 
*  (Z--  M2)  **  2)  /  SI) 

Print  'Intercept  =  ';A 

Print  ' Slope  =  ' ;E 

Print  'Correlation  Coefficient  = • {CORRELATION 

Print  'Standard  Error  of  Slope  =':B1 

INTERVAL  =  1 

WHILE  INTERVAL  <=  LAST  OBSERVED  INTERVAL 
ESTIMATE  =  Function“R (  END  INTERVAL)  ) 
UPPER  =  ESTIMATE  +  (  VARIATE 

*  Function  F(  END  INTERVAL)  ) 

LOWER  =  ESTIMATE  -  (  VAEIITE 

*  Function  F(  END  INTERVAL)  ) 

INTERVAL  =  INTERVAL  +  1  “ 

End  While. 

INTERVAL  =  LAST  CESERVED  INTERVAL  *  1 

While  interval  LAST  INTERVAL  NUMBER 
ESTIMATE  =  Function-R(  END  INTERVAL)  ) 
UPPER  =  ESTIMATE  ♦  {  VARIATE 

*  Function  F(  END  INTERVAL)  ) 

LOWER  =  ESTIMATE  -  (  VARlITE 

*  Function  F(  END  INTERVAL)  ) 

INTERVAL  =  INTERVAL  +  1  ~ 

End  While. 


Function 

Function 


Print 

Print 

Print 

Print 


/ 

DATA  POINTS 
)  /  SI)) 


uuLJUiiu 

!(  END  INTERVAL) 
VARIATE 


TABLE  26 

Process  4.3.4  Basis  Paths 


Complexity  Metric:  3 

1.  atcdefghmnot 

2.  atcdefghi jklmnct 

3.  atcdefghmnopgrst 


to  lOtjnasscf 


************************************************************ 
4.3.5  LCG  CURVE  FORECAST 


Inpats:  VARIATE 

IDENTIFIER 
REGRESS  ANALYSIS 

factor  View 

MODEL  VIEW 


Source:  Process  4.3.1 
Process  4.3.1 
Process  4.  3.  1 
Process  4.3.1 
Process  4.3.1 


Outputs:  EXPANDED  MODEL  VIEW  Destination:  Manager 
EXPANDED- FACTOR  VIEW  Manager 

EX P AN D ED- FACTOR- VI EW  Process  4.3.1 


A. 

B. 


C. 

D. 

E. 

F. 

G. 

H. 

I. 

J. 


Define  Function  R  (Z)  = 
Define  Function  F  (Z)  = 


Print 

Print 

Print 

Print 


=  A  +  3  *  Z 

03  *  SQR ( 1  +  1  / 

(DATA  POINTS  ♦  (DATA  POINTS 
*  (Z--  M2)  **  2)  /  SI)  ) 
•Constant  Term  =  *;eX?(A) 

'  Growth  Rate  =  ' :  3 

•Correlation  Coefficient  =•; CORR ELATION 


Error  of  Growth  Rate  =’;31 


*  Standard 
INTERVAL  =  1 
While  INTERVAL  <=  LAST  OBSERVED  INTERVAL 

ESTIMATE  =  EXP J  Function  R(  END  INTERVAL) 
UPPER  =  ESTIMATE  +  (  VARIATE 

*  Function  F(  END  INTERVAL)  ) 
LCWER  =  ESTIMATE  -  (  VARIlTE 

*  Function  F(  END  INTERVAL)  ) 

INTERVAL  =  INTERVAL  ♦  1  “ 

End  While. 

INTERVAL  =  LAST  OBSERVED  INTERVAL  ♦  1 
While  INTERVAL  ?=  LAST  INTERVAL  NUMBER 

ESTIMATE  =  EXP  (  Function  R(  END  INTERVAL) 
UPPER  =  ESTIMATE  +  (  VARIATE 

*  Function  F(  END  INTERVAL)  ) 
LCWER  =  ESTIMATE  -  (  VARISTS 

*  Function  F(  END  INTERVAL)  ) 

INTERVAL  =  INTERVAL  ♦  1  - 

End  While. 


)  ) 


)  ) 


TABLE  27 

Process  4.3.5  Basis  Paths 

Complexity  Metric:  3 

1.  atcdefghmnot 

2.  atcdefghi jklmnct 

3.  atcdefghmnopqrst 
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4.3.6  DOUBLE  LOG  CURVE  FORECAST 


Inputs:  VARIATE 

IDENTIFIER 
REGRESS  ANALYSIS 
FACTOR  VIEW 
MODEL_VlEW 

Outputs:  EXPANDED  MODEL  VIEW 
EXPANDED- FACTOR  VIEW 
EXPANDED- FA CTCR-V IE W 


Source:  Process  4.3.1 
Process  4.3.1 
Process  4.3.1 
Process  4.3.1 
Process  4.3.1 

Destination:  Manager 
Manager 
Process  4.3.1 


A.  Define  Function  R  (Z)  =  A  +  B  *  Z 

B.  Define  Function  F  (Z)  =  03  *  SQR(1  +  1  / 

(DATA  POINTS  +  (DATA  POINTS 
*  (Z--  M2)  **  2)  /  SI) ) 

C.  Print  'Constant  =  ’;EXP(A) 

D.  Print  'Power  =  '  ;E 

E.  Print  'Correlation  Coefficient  =' {CORRELATION 

F.  Print  'Standard  Error  of  Power  =';B1 

G.  INTERVAL  =  1 

H.  While  INTERVAL  <=  LAST  OBSERVED  INTERVAL 

I.  ESTIMATE  =  EXP  (  Function  R(  L0G(  END  INTERVAL)  )  )  ) 

J.  UPPER  =  ESTIMATE  ♦  (  VARIATE 

*  Function  F(  END  INTERVAL)  ) 

K.  LOWER  =  ESTIMATE  -  (  VARIUTE 

*  Function  F(  END  INTERVAL)  ) 

INTERVAL  =  INTERVAL  ♦  1  - 

End  While. 

INTERVAL  =  LAST  CESERVED  INTERVAL  +  1 
While  INTERVAL  Z=  LAST  INTERVAL  NUMBER 

ESTIMATE  =  EXPJ  Function  R(  IOG (  END  INTERVAL)  )  )  ) 
UPPER  =  ESTIMATE  ♦  {  VARIATE 

*  Function  F(  END  INTERVAL)  ) 

LOWER  =  ESTIMATE  -  (  VARIlTE 

*  Function  F(  END  INTERVAL)  ) 

INTERVAL  =  INTERVAL  +  1  - 

End  While. 


TABLE  28 

Process  4.3.6  Basis  Paths 

Complexity  Metric:  3 

1.  atcdefghmnot 

2.  ahcdefghi jk lmnct 

3.  atcdefghmnopqrst 
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************************************************************ 
4.4.1  MCNTE  CARLO 

Inputs:  FIRM  SELECT  Source:  Process  4.1 

EXPANDED  FACTOR  VIEW  Process  4.J 

MODEL  VIEW  ~  Process  4. 1 

MODEL_STRUCTnRE  Process  4.1 

MCDEL^SCORE  Process  4.4.2 

Outputs:  MONTECARLO  FORECAST  Destination:  Manager 

MODEL  STRUCTURE  Process  4.4.2 

AVG  VlLUE  Process  4.4.2 


.  For  each  FACTOR  IE  in  MODEL  STRUCTURE 
Do  C  -RVE  FUNCTION 

End  For 

INTERVAL  NUMBER  =  1 

While  INTERVAL  NUMBER  <=  LAST  OBSERVED  INTERVAL 
Do  CALCULATE  MODEL  SCORE  ~ 

AVG  VALUE  =  ESTIMATE  (FACTOR  ID) 

Do  CALCULATE  MODEL  SCORE 
ESTIMATE (MODEL  ID)  =  MODEL  SCORE 
INTERVAL  NUMBER  =  INTERVAL- NUMBER  +  1 
Print  using  OBSERVED  DATA  FORMAT 

End  While. 

While  INTERVAL  NUMBER  <=  LAST  INTERVAL  NUMBER 
AVG  VALUE  =“ESTIMATE (FACTOR  ID) 

Do  CALCULATE  MCDEL  SCORE 
ESTIMATE (MODEL  ID)  =  MCDEL  SCORE 
AVG  VALUE  =  UPFERfFACTOR  ID) 

Do  CALCULATE  MODEL  SCORE- 
UPPER  (MODEL  IE)  =  MODEL  SCORE 
AVG  VALUE  =~LCWER  (FACTOR  ID) 

Do  CALCULATE  MODEL  SCORE- 
LOWER  (MODEL  IE)  =  MODEL  SCORE 
Print  using-ESTIMATED  DUTA  FORMAT 
COUNT  =1  - 

While  COUNT  <=  ITERATIONS 

For  each  FACTOR  ID  in  MODEL  STRUCTURE 
AVG  VALUE  =“{  (UPPER  (FACTOR  ID) 

-  LOWER (FACTOR  ID)) 

*  RANDOM  NUMBER)  ♦  LOWER (FACTOR  ID) 

E’  .  End  For. 

C’.  Do  CALCULATE  MODEL  SCORE 

D*.  FREQUENCY  (INTERVAL  NUMBER , COUNT)  =  MODEL  SCORE 

E’  .  COUNT  =  COUNT  +  1  “ 

F’.  End  While. 

G».  I NTERVAL_NUMBEE  =  INT ER VAL_NU MBER  +  1 

H* .  Print  Frequency  Distribution 

I'.  End  While. 


*qp_KJ«  WlnOKH  TSCHEZ  O  Ui  rj»0- 


TABLE  29 

Process  4.4.1  Basis  Paths 


Complexity  Metric:  6 

1.  acdelmi' 

2.  atcdelmi' 

3.  acdefghi jklmi  ' 

4.  acdelmnopqrstuvwxyf * g 'h 'i * 

5 .  acdelmnopqrstuvwxyzb1 c' d'e'f'g'h’i' 

6 .  acdelmnopqrst uvwxyza 'b'c'd'e'x'g'h’i’ 


**************  **************  **************  ********  ********** 
4.4.2  CALCULATE  MOD  El  SCORE 


Inputs:  MODEL  STRUCTURE 
AVG_VELUE 

Outputs:  MODEL_SCORE 


Source:  Process  4.4.1 
Process  4.4.1 

Destination:  Process  4.4.1 


Fcr  Each  GROUP 

If  GROUP  LEVEL  =  1 
For  each  SUE  GROUP 

Sum  the  value  of  the  AVG  VALUES  multiplied  by 
the  FACTOR  WEIGHTS  for  each  FACTOR  ID 
Multiply  this  sum  by  the  SUB  GROUP  WEIGHT 
Remember  this  as  the  S UB_GROTJP_VALHE 
End  For 

Multiply  the  SUB  GROUP  VALUES  together 
Multiply  the  SUB“GROUP”VALUE  by  the 
GROUP  WEIGHT” 

Remember  this  as  the  GROUP  VALUE 
End  If. 

End  For. 

If  there  are  2  groups  with  a  GROUP  LEVEL  =  1  then 
DIVIDE  THE  GROUP  VALUE  of  the  GROUP  which  has  a 
GROUP  TYPE  =”"Desirable"  by  the  GROUP  VALUE 
of  the  GROUP  which  has  GROUP  TYPE  equal  to 
"Undesirable" 

Remember  this  number  as  MODEL  SCORE 
End  If 

For  each  GROUP 

If  GROUP  LEVEL  =  0 

GROU P”VALU  E  =  AVG  VALUE  *  GROUP  WEIGHT 
Multiply  the  GROUP  VALUE  times  the  MODEL  SCORE 
Remember  this  result  as  the  MODEL  SCORE  ” 

End  If. 

End  For. 


9  1 


TABLE  30 

Process  4.4.2  Basis  Paths 


Complexity  Metric:  7 

1.  almpqw 

2.  atklmpqw 

3.  atcghigklmpqv 

4.  alcaefghi jklmpgw 

5.  almnopqw 

6.  almpqrvw 

7.  almpqrstuvw 


**^^^^*m****** ***********************************  *********** 

5.1  CROSS  IMPACT 

Inputs:  FACTOR  ID  Source:  Process  2.0 

IMPACT- FACTORS  FACTOR  File 

FACTOR- IMP ACTS  FACTOR  File 

Outputs:  CROSS  IMPACT  MATRIX  Destination:  Manager 

CROSS- IMP ACT—MATRIX  Process  5.2 


A.  Identify  the  FACTOR  ID  to  observe 

E.  Get  list  of  IMPACT  "FACTORS 

C.  N 1  =  Number  of  IMPACT  FACTO Fs 

D.  For  OBJECT  =  FIR  ST'LABT  of  set  of  IMPACT  FACTORS 

E.  Get  list  of  IMPACT  FACTORS  for  each  OBJECT 

F.  For  IMPACT  =  FIBSTTLAST  of  set  of  IMPACT  FACTORS 

G.  If  the  IMPACT  FACTOR  is  not  listed  in-the  WORK 

File  as  an  IMPACT  FACTOR  on  the  OBJECT 
then 

H.  CROSS  IMPACT  MATRIX  (  OBJECT, IMPACT  )  =  0 

Else  -  “ 

I.  CROSS  IMPACT  MATRIX (  OB J ECT,  IM PACT  )  = 

FACTOR  I7TPACT 

J.  End  If 

K.  End  For. 

L.  IMPACT  =  OUTSIDE  WORLD 

M.  CROSS  IMPACT  MATRIX {  OBJECT, IMPACT  )  =  WORLD  IMPACT 

N.  End  For. 


z:x  m  w  CjHaOMWdD 


TABLE  31 

Process  5.  1  Basis  Paths 


Complexity  Metric; 

1 .  alcdn 

2.  atcdefklmn 

3.  alcdefgi jklmn 

4.  atcdef gh jklmn 


************************************************************ 
5.2  CALCULATE  IMPACT 

Inputs:  CROSS  IMPACT  MATRIX  Source;  Process  5.1 
INITIXL_VALUE  Manager 


Outputs:  RELATIVE  TIME 
VALUE 


Destination:  Manager 
Manager 


,  ATIVE  TIME  =  0 

:  CBJECT=  FIRST'LAST  of  set  of  IMPACT  FACTORS  S 
OUTSIDE  WORLD 
Do  CALCULATE  INITIAL  VAIUE 
VALUE  (OBJECT)  =  INITIAL  VALUE 
l  For 

5E  INTERVAL  =  0.001 
:  RELATIVE  TIME=  1  to  1000 

For  IMPACT  =  FIRST’LAST  of  set  of  IMPACT  FACTORS 
NEGATIVE  (IMPACT)  =  DESIRABLE  (IMP ACT)  =  0 
For  OB JECT=  FIRST'LAST  of  set  of  IMPACT  FACTORS 
OUTSIDE  WORLD 

NEGATIVE1IMPACT)  =  NEGATIVE  (IMPACT) 


NEG ATIV E  (I MP ACT )  =  NEGATIVE f IMPACT) 

*  (  (ABS  (CROSS  IMPACT  MATRIXjlMPACT.CEJECT)  )  ) 
-  CECSS  IMPACT  MATRIX  (IMPACi, OBJECT)  ) 

*  VAIUETOBJECTf 

DESIRABIE(IMPACT)  =  DESIRABLE  (IMPACT) 

*  ({AES  (CROSS  IMPACT  MATRIX (IMPACT.OBJECT) ) ) 

*  CROSS  IMPACT  MATRIX  (IMPACT, OBJECT) ) 

*  VAIUElOBJECTf 
End  For. 

E  (IMPACT)  =  (1  +  TIME  INTERVAL  *  (0.5) 

*  NEGATIVE  (IMPACT)  )  / 

(1  *  TIME  INTERVAL  *  (0.5) 

*  DESIRABLE  (IMPACT)  ) 

End  For. 

For  IMPACT  =  FIRST’LAST  of  set  of  IMPACT  FACTORS 
VALUE  (IMPACT)  =  VALUE  (IMPACT)  **  E  (IMPACT) 

If  VALUE  (IMEACT)  <=  1.0  **  (-70)  then 
VALUE  (IMPACT)  =  0 
End  If. 

End  For. 

1  For 


TABLE  32 

Process  5. 2  Basis  Paths 


Complexity  Metric:  7 

1.  alefgv 

2.  alcdefgv 

3.  alefghopuv 

4.  afcef ghigmnopuv 

5.  alef ghigklmnopuv 

6.  afceghi jmnopgrstuv 

7.  afceghig mnopgr tuv 


to  two  o  as  3  h  ^  Cj  h  va  a  ^  w  o  n  ca  > 


*********************************************************** 
6  MODEL  CHANGE 


Inputs:  INITIAL  VALUE 
EACTOR  VIEW 
MODEL  STRUCTURE 
CROSS- IMPACT  MATRIX 
FIRM  SELECT  ~ 

GROUP  WEIGHT 
SUB  GROUP  WEIGHT 
FACTOR  WEIGHT 
FACTOR-LIMIT 
MODELJTD 

Outputs:  MCDEL  STRUCTURE 
MODEL-STRUCTURE 

FACTOR  VIEW 

CROSS  IMPACT  MATRIX 

INITIAL  VALUE 


ource:  Process  5 
Process  4 
Process  4 
Process  5 
Process  2 
Manager 
Manager 
Manayer 
Manager 
Manager 

Destination:  Process  4 

MODEL  STRUCTURE 
File 

Process  4 
Process  5 
Process  5 


Get  FIRM  SELECT 

If  IDENTIFIER  is  a  MODEL  ID  and  CHANGE  =  "Model"  then 
Change  one  of  the  following  variables 
{GROUP  WEIGHT} 

SUB  GROUP  WEIGHT} 

FACTOR  WEIGHT} 

End  If 

If  CHANGE  =  "Factor"  then 
For  each  FACTOR  ID 

Change  FACTCR_LIMIT  if  desired 
End  For. 

End  If 

If  CHANGE  =  "Selection"  then 

Change  one  of  the  following  variables 
CHOICE 
WINDOW 
INTERVAL 
End  Change. 

End  If. 
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TAi3LE  33 

Prccess  6  Basis  Paths 


Ccitflexity  Metric:  5 

1.  atghlms 

2.  atcdefahlms 

3.  atghiiKlms 

4.  atghiRlns 

5.  atghlmnopgrs 


APPENDIX  C 
DATA  DICTIONARY 


A.  DATA  FLOW  COHPOSITIONS 


EARE_FACTOR_VIEW 

EARE_MODEL_VIEW 

CROSS_IMPACT_MATRIX 
ELEM  ENT_ENTRY 

EXPANDED  FACTOR  VIEW 


FACTOR  ID 
(FACTO I?  LIMIT) 

WINDOW  ~ 

INTERVAL 
(INTERVAL  NUMBER 
BEGIN  INTERVAL 
END_  INTERVAL} 

MODEL  ID 
jMODEI  LIMIT) 

WINDOW” 

INTERV  AL 

(INTERVAL  NUMBER 
BEGIN  INTERVAL 
END_INTERVAL) 

FACTOR  ID 
(IMPACT  FACTOR 
FACTO R”IMP ACT} 

DATE  OF  OBSERVATION 
{ELEMENT  ANALYSIS 
ELEMENT"SOURCE 
DATE  OF“EWTRY 
ELEMENT^VALUE} 

FACTOR  ID 
(FACTOR  LIMIT) 

WINDOW  ” 

INTERVAL 

LAST  OBSERVED  INTERVAL 
LAST”INTERVAL”NUMBER 
(INTERVAL  NUMBER 
BEGIN  INTERVAL 
END  INTERVAL 
A VG”VALUE 
(ESTIMATE 
UPPER 
LOWER) 

OBSERVED} 


EXPAN  EE E_MODEL_VIEW 

=  MODEL  ID 

(MODEr  LIMIT) 

WINDOW" 

INTERVAL 

LAST  OESERVED  INTERVAL 
LA  ST"I NTERV  A  L~NUMB  ER 
{INTERVAL  NUMBER 

BEGIN  INTERVAL 

END  IDTERVAL 

MODEL  SCORE 
(ESTIMATE 

UPPER 

LOWER) 

OBSERVE) 

FACTOR 

=  FACTOR  ID 

FACTOR~TYPE 
CHARACTERISTIC 
(UNITS  ♦  FACTOR  LIMIT) 
(IMPACT  FACTOR  " 

FACTO  R"IMPACT) 
OUTSIDE"WORLD 
(ELEMENT_ENTRY) 

FAC  TOB_VIEW 

=  FACTOR  ID 

(FACTOR  LIMIT) 

WINDOW  " 

INTERVAL 

LAST  OBSERVED  INTERVAL 
LAST"I NTERV AL"NUMBER 
(INTERVAL  NUMBER 

BEGIN  INTERVAL 

END  IETERVAL 

AVG~VALUE 

OBSERVED) 

FIRM_SELECT 

=  IDENTIFIER 

CHOICE 

VALIDATION 

WINDOW 

INTERVAL 

(ITERATIONS) 

IDENTIFIER 

=  [ MODEL_ID| FACTOR_ID ] 

MODEL  STRUCTURE 


MODEL  VIEW 


REGRESS  ANALYSIS 


SUB_GEOUP 

USER  SELECT 


MODEL  ID 
{GROUP  ID 
GRO  UP'LEVEL 
GROUP'W  EIGHT 
(GROUP  TYPE) 
{SUB_GEOUP} 

MODEL  ID 
(MODE!  LIMIT) 

WINDOW' 

INTERVAL 

LAST  OBSERVED  INTERVAL 
L AST'I NT  ERV AL'NUMBER 
[INTERVAL  NUMBER 
BEGIN  INTERVAL 
END  INTERVAL 
MODEL  SCORE 
OBSERVE} 

IDENTIFIER 

CURVE 

VARIATE 

B 

A 

STANDARD  ERROR 

CORRELATION 

03 


SUB  GROUP  ID 
SUB~GROUP“W EIGHT 
1  {FACTOR  ID 

FACTOR^WEIGHT} 

IDENTIFIER 

CHOICE 

(WINDOW) 

(INTERVAL) 

(ITERATIONS) 


WINDOW 


BEGIN  PERIOD 
END  PERIOD 


B.  DATA  ELEHES: 
A 

AVG_ V  ALUE 

E 

EEGI N_I NTEKVAL 

BEGI N_ EEKIOD 

CHARACTERISTIC 

CHOICE 


CORREIATICN 


DESCRIPTIONS 

=  type  is  digits  7 

*  Temporary  variable  in 
regression  calculation  * 

=  type  is  digits  7 

*  Average  of  all  data  elements  in 
a  defined  interval  * 

First  defined  in  4.0 

=  type  is  FLOAT 

*  Temporary  variable  in 
regression  calculation  * 

=  type  is  range  0..100_000 

*  Julian  date  representation  of 
the  date  of  the  beginning  of  an 
interval.  Base  year  is  1900  * 

=  type  is  range  0..100_000 

*  Julian  date  representation  of 
the  date  of  the  beginning  of 
a  period.  3ase  year  is  1900  * 

=  type  is  (Endogenous,  Exogenous) 

*  Identifies  whether  a  FACTOR  is 
within  users  control  or  not  * 

=  type  is  (Forecast,  Monte-Carlo, 
Cross-Matrix) 

*  Identify  whether  to  run  a 
forecast  model  or  the  cross- 
impact  simulation  * 

=  type  is  digits  7  range  0.0. .1.0 

*  This  is  the  R  **  2  result  of 
regression  analysis  * 


100 


CURVE  =  type  is  (Pearl,  Gompertz,  Linear, 

Log,  Double-Log) 

*  Selection  of  curve  function  to 
utilize  * 

BATE_OF_ENTRY  =  type  is  range  0..100_000 

*  Julian  date  ELEMENT. ENTRY  is 
placed  in  the  data  base  * 

EATE_OF_CBSERVATION  =  type  is  range  0..  100.000 

*  Julian  date  ELEMENT.ENTRY' s 
E LEM ENT_ VALUE  is  observed  * 

EL EM ENT_ ANALYSIS  =  type  is  (Historical, Estimate) 

*  Indicator  of  whether  data  is 
Observed  or  a  DSS  generated 
Estimate  * 

ELEMENT_SOURCE  =  type  is  STRING ( 1 . .30) 

*  Source  of  data  for 
ELEMENT_ENTRY  * 

ELEMENT. VALUE  =  type  is  digits  7 

*  Value  of  ELEMENT.ENTRY  * 

END.INTERVAL  =  type  is  range  0..  100.000 

*  Julian  date  representation  of 
the  date  of  the  ending  of  an 
interval.  Base  year  is  1900  * 

END.PER ICD  =  type  is  range  0..  100.000 

*  Julian  date  representation  of 
the  date  of  the  ending  cf 

a  period.  Base  year  is  1900  * 

ESTIMATE  =  type  is  digits  7 

*  An  ELEMENT.VALUE  generated  by 
the  DSS  * 
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FACTCE_ID  =  type  is  STRING  ( 1.  . 2 1) 

*  Unique  name  of  a  FACTOR  in  the 
format  • F. XXXXXXXXXX. TTTTTTTT • . 
The  ’F.'  indicates  it  is  a 
FACTOR_ID,  the  'X'  is  for  the 
name  within  a  technology,  the 
'T*  is  for  the  technology  * 

FACT  CR_  IMP  ACT  =  type  is  STRING  (1.21) 

*  The  FACTOR_ID  of  a  FACTOR  which 
has  an  impact  on  the  key 
FACTOR  * 

FACTOR_LIMIT  =  type  is  digits  7 

*  Highest  value  which  an  ELEME NT_ 
VALUE  may  ever  be.  Could  be  a 
null  value  if  there  is  no 
limit  * 

FACTGF_TYPE  =  type  is  ( Sub jec tive, Ob j ecti ve) 

*  Indicator  of  whether  a  FACTOR 
is  a  subjective  or  objective 
value  * 

FACTCF_WEIGHT  =  type  is  delta  0.1  range  0.C..1.0 

*  a  subjective  weighting  of  a 
FACTORS  impact  in  a  model  * 

GR0UP_ID  =  type  is  STRING  (  1 .. 2 1) 

*  Unique  name  of  a  GROUP  in  the 
format  'G.  XXXXXXXXXX. TTITTTTT* . 
The  'G.*  indicates  it  is  a 
GROU P_ID,  the  'X’  is  for  the 
name  within  a  technology,  the 
’T*  is  for  the  technology  * 


GROUP  IEVE1 


=  type  is  range  0..1 

*  Indicator  of  which  GROUPS  act 
upon  other  GROUPS.  Low  numbers 
act  on  high  numbers  * 

GROUF_TYFE  =  type  is  (Desirable, Undesirable) 

*  Indicator  of  whether  a  GROUP  is 
a  desirable  value  or  an 
undesirable  value  * 

GROUP_WEIGHT  =  type  is  delta  0.1  range  0.0.. 1.0 

*  a  subjective  weighting  of  a 
GROUPS  impact  in  a  model  * 

IMPACT_ FACTOR  =  type  is  delta  0.1  range  0.0.. 1.0 

*  Subjective  value  of  the  impact 
of  one  FACTOR  upon  another  * 

INTERVAL  =  type  is  range  1..100_000 

*  Length  of  each  interval  over 
which  to  average  data  values 
for  forecasting  as  measured  in 
days  * 

INTEFVAL_NUMBER  =  type  is  range  1..400 

*  Number  of  intervals  in  the 
WINDOW  defined  by  the  user  * 

ITERATIONS  =  type  is  range  1..500 

*  Number  of  types  to  execute 
Monte  Carlo  simulation  * 


1A ST_INTER V  AL_NU MB ER  =  type  is  range  1..400 

*  last  INTER7AL_NUMBER  in  WINE 
defined  by  the  user  * 

LAST_CES£RVED_INTER V A I  =  type  is  range  1..400 

*  Last  interval  which  contains 
data  which  is  Historical  * 

type  is  digits  7 

*  The  lower  value  of  the 
confidence  limit  for  an 
interval  in  regression 
analysis  * 

type  is  STRING  (1..21) 

*  Unique  name  of  a 
MODEL_STRUCTURE  in  the 
format  • M. XXXXXXXXXX. TTTTTTTT* . 
The  '  M .  '  indicates  it  is  a 
MODEL_ID,  the  'X'  is  for  the 
name  within  a  technology,  the 
* T*  is  for  the  technology  * 

type  is  digits  7 

*  Temporary  variable  in 
regression  calculation  * 

type  is  range  0..1000 

*  Number  of  EL  EM  ENT_V  ALUES  in  an 
INTERVAL  * 

CUT S IE E_ WORLD  =  type  is  delta  0. 1  range  0.0. .1.0 

*  Subjective  impact  of  world  upon 
a  FACTOR  * 

=  type  is  digits  7 

*  Temporary  variable  in 
regression  calculation  * 


LOWER 


MODEL  ID 


M2 


CESERVED 


C3 


RELATIVE_T IME  =  type  is  range  0..1000 

*  An  counter  of  relative  time 
periods  in  the  Cross  Impact 
Analysis  * 

STAND A FD_ERROR  =  type  is  digits  7 

*  The  standard  error  of  the 
estimate  of  the  dependent 
variable  in  the  regression 
analysis  * 

SU9_GR0  UP_ ID  =  type  is  STRING (  1. . 21) 

*  Unique  name  of  a  SUB_GROUP  in 
format  'S. XXXXXXXXXX. TTTTTTTT'  . 
The  * S . ’  indicates  it  is  a 
SUB_GROUP_ID,  the  'X*  is  fcr 
name  within  a  technology,  the 

* T*  is  for  the  technology  * 

SU3_GROUF_VEIGflT  =  type  is  delta  0.1  range  0.0.  .1.0 

*  a  subjective  weighting  of  a 
SUB_GROUPs  impact  in  a  model  * 

Si  =  type  is  digits  7 

*  Temporary  variable  in 
regression  calculation  * 

UNITS  =  type  is  STRING(1.  .20) 

*  Units  of  measure  for 
ELEMENT  VALUES  * 
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UPPER 


=  type  is  digits  7 

*  The  upper  value  of  the 
confidence  limit  for  an 
interval  in  regression 
analysis  * 

VALIDATION  =  type  is  (Valid, Not-Valid) 

*  Indicator  of  whether  a 
USER_S ELECT  is  acceptable  * 

VARIATE  =  type  is  delta  0.001 

range  0 .000. .  1.  000 

*  Value  to  determine  the 
confidence  interval  in 
analysis  * 
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